Fixing const arrays
deadalnix
deadalnix at gmail.com
Sun Dec 11 14:33:31 PST 2011
Le 11/12/2011 22:34, Jonathan M Davis a écrit :
> 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.
>
> 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.
>
> Now, if we're talking only IFTI - such func(cast(immutable int)2) instantiates
> with int and func!(immutable int)(2) still instantiates with immutable int -
> and it's only for primitives by themselves (e.g. func above is unaffected),
> then it likely isn't a problem. But we need to really look at the side effects
> of trying to treat primitives as mutable in templates.
>
> And if you're going to do that with primitives, it also opens up the question
> as to what to do with structs which are value types. Should they be treated
> the same?
>
> In theory, I think that stripping const and immutable from primitives at the
> top level could be a nice thing to have, but I'd be very concerned about how
> that would be implemented and what it would affect. We risk losing valuable
> type information and breaking existing code if it's not done right.
>
> - Jonathan M Davis
I think you misunderstood the idea. The point was to remove constness of
something passed by value, as long as it possible (native types, pointer
(but not pointee), slices (but not what is in the slice), structs as
long as they have no indirection in them).
Has thoses are passed by value, the templated code will manipulate a
copy of the data. So the original data can be immutable and the copied
data can be mutable. This is not a big deal as theses data are
differents ones.
More information about the Digitalmars-d
mailing list