On Saturday, May 26, 2012 13:05:00 Jacob Carlborg wrote:
> On 2012-05-26 01:17, Jonathan M Davis wrote:
> >> Ok I see, thanks. Is that true for fields in structs and global
> >> variables as well?
> >
> > Anyway, I suppose that that's not terribly conclusive, but the lack of
> > ability to have non-transitive const declarations is a bit of a problem
> > when dealing with extern(C) functions given that it has behaviors that D
> > _doesn't_ have. As far as I can see, whether constifying the whole thing
> > or making it all mutable makes more sense really depends on what the C
> > function is doing and how it's called, which naturally doesn't go well
> > with a tool like you're creating. You'll probably have to go with what is
> > _least_ likely to cause bugs and then let the programmer adjust it as
> > needed.
> >
> > - Jonathan M Davis
>
> What do you think about translating the C const to D where possible and
> then just leave it mutable in all other cases. Then assuming the C code
> will not cast away const. A user is always free to edit the bindings
> manually.
That seems like a good approach, since then you're not marking things as const
in D that C would consider mutable and therefore be likely to be altered,
breaking D's guarantees. It does make me think that it could be valuable to
include a comment with the original declaration though (at least in cases
where a direct translation isn't possible). That way, it would be clearer that
the signature in D isn't quite right. e.g.
/**
Comment
*/
extern(C) void func(int*const* param);
becomes something like
/**
Comment
*/
extern(C) void func(int** param);
//orig: void func(int*const* param);
- Jonathan M Davis
