On Saturday, 16 December 2017 at 11:19:36 UTC, Mike Parker wrote:
that's a binding, not a wrapper.
Right!
Not sure what you mean by "safe"
you only want to prevent changes on the D side and don't care
if they happen on the C side, then that's fine.
This, yes. I'd like const-annotated D code because of the static
checks, without risking bugs from aggressive compiler
assumptions. It's fine it the C side mutates privately.
I am ready to take responsibility in case I misjudge whether one
of the C functions mutates detectable state or not.
Question 2. If yes, can the wrapper sanely declare foo(const
A*) instead of foo(A*)?
if you pass immutable variables to the function -- if the
parameter is const even when the function modifies the
variable, D will allow immutable to be passed and you're
looking at unexpected behavior.
This is the heart of the problem, I've overlooked this.
None of my A are immutable, but declaring the bindings as
foo(const A*) would take immutables.
I would expect SiegeLord to reject such a PR.
Only add const to parameters in C function declarations if
the C API actually declares those parameters as const.
That was my hunch, too. I've asked upstream on the Allegro
forums. It would be a drastic change, I'd wager there won't be
any const in the API anytime soon. But I'll give them the due
time to decide.
If no const C API, I'd stick to private wrappers around
DAllegro5, with a codebase-wide rule to not pass immutable.
In principle, I disagree with him
how much weight should be assigned to "probably".
Hmm, SiegeLord is a core Allegro 5 developer, he could judge
overriding the C API's promises. But I share your sentiment that
the public C API should have the final word.
Many thanks for the high-quality answer!
-- Simon
