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