Fixing const arrays
Jonathan M Davis
jmdavisProg at gmx.com
Sun Dec 11 14:19:26 PST 2011
On Sunday, December 11, 2011 23:13:39 Timon Gehr wrote:
> On 12/11/2011 10:34 PM, Jonathan M Davis wrote:
> > On Sunday, December 11, 2011 10:34:40 Andrei Alexandrescu wrote:
> >> On 12/11/11 9:46 AM, dsimcha wrote:
> >>> On 12/10/2011 4:47 PM, Andrei Alexandrescu wrote:
> >>>> We decided to fix this issue by automatically shedding the
> >>>> top-level
> >>>> const when passing an array or a pointer by value into a function.
> >>>
> >>> Really silly question: Why not do the same for primitives (int,
> >>> float,
> >>> char, etc.) or even structs without indirection? I've seen plenty of
> >>> code that blows up when passed an immutable double because it tries
> >>> to
> >>> mutate its arguments. About 1.5 years ago I fixed a bug like this in
> >>> std.math.pow().
> >>
> >> Yes, that would be good to do as well.
> >
> > Actually, that could be a problem for some stuff. It might be an
> > acceptable problem, but it creates a problem nonetheless. What about
> > containers? You can have arrays with immutable elements, but if you
> > made it so that immutable int and int were the same as far as templates
> > were concerned, then it would be impossible to have a container which
> > held immutable elements. How big of a problem that is, I don't know,
> > but I'd be concerned about some of the side effects.
>
> Those issues are inexistent. int and immutable(int) are implicitly
> convertible to each other.
They may be implicitly convertible, but if you just outright stripped const
and immutable from primitives, it would become impossible to instantiate a
container which held const or immutable elements which were primitive.
> > Another concern would be what would happen with primitives when they're
> > inside of arrays. e.g.
> >
> > void func(T)(T[] arr)
> >
> > Having T lose its constness would be a big problem here.
>
> Nobody suggested to do that.
That may be, but depending on how the removal of const on primitives were
applied, it would happen. We need to make sure that it _doesn't_ happen.
My point was not that this is a horrible idea but rather that we need to make
sure that it targets what it's supposed to target and does not have side
effects that reduce D's current capabilities.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list