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.
>> 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.

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

On 12/11/2011 11:19 PM, Jonathan M Davis wrote:
> 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.
>
MyContainer!(immutable(int)).
>>> 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
The qualifiers are stripped from the actual arguments, not from the template arguments.

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.

On 12/11/11 4:19 PM, Jonathan M Davis wrote:
> 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.
Timon is right, there's no issue. Top-level qualifier would be stripped ONLY when passing by-value into a function.
Andrei

On 12/12/2011 12:33 AM, deadalnix wrote:
> 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).
Then, should the rule be generalized to include any type that has no indirections to mutable data?
struct S2
{
immutable(int)* x;
}
struct S
{
string s;
S2 s2;
}
void foo(T)(T s) if (!is(T == immutable)) { }
immutable S s;
foo(s);
The argument is passed by value, the qualifier can be safely removed, so the call is rewritten to
foo(cast(S)s);
Any potential problems with that?

On 12/11/2011 11:24 PM, Jonathan M Davis wrote:
> On Sunday, December 11, 2011 14:54:27 Tobias Pankrath wrote:
>>> Specifically:
>>>>>> "Properties should behave as if they are fields; if the method cannot,
>>> it should not be changed to a property.
>>> Methods are better than properties in the following situations:
>>>>>> - Calling the method two times in succession creates different results.
>>> - The method performs a time-consuming operation. The method is
>>> perceivably slower than the time that is required to set or get the
>>> value of a field."
>>>>>> Since both of these can be true for all but the most trivial kinds of
>>> ranges (e.g. file-system-related enumerators/ranges would very likely
>>> need to re-open a handle to a directory in order to traverse it, which
>>> is both relatively time-consuming AND returns a different result every
>>> time, and could even unexpectedly fail due to permission/connectivity
>>> issues), I don't think it makes sense for save() to be a @property.
>>>> I agree.
>> It was debated some time ago, and it ended up being a property. The fact that
> save is an action verb and not a noun automatically disqualifies it as a
> property IMHO, but it was made into a property, and we're pretty much stuck
> with it at some point. As far as what the function does, I don't think that
> it's a problem that it's a property, but it's not named like a property, so
> the situation with regards to save is not ideal, but it's too late now.
>> - Jonathan M Davis
Reminds me of .NET's Object.GetHashCode() method, which should be a property according to their guide. Another is Object.GetType() - why is it not a property anyway? Both are supposed to return the same value on succesive calls and both are computationally cheap.
Other examples are widget size setters that can be computationally quite expensive (resizing child widgets, etc.). They are usually property setters regardless of the fact that they are "perceivably slower" to set than fields.

On 11.12.2011 22:24, Jonathan M Davis wrote:
...
> It was debated some time ago, and it ended up being a property. The fact that
> save is an action verb and not a noun automatically disqualifies it as a
> property IMHO, but it was made into a property, and we're pretty much stuck
> with it at some point. As far as what the function does, I don't think that
> it's a problem that it's a property, but it's not named like a property, so
> the situation with regards to save is not ideal, but it's too late now.
I really don't get this. When D has 10,000 programmers using it professionally, it's too late. But now it's more like 5 or 10. And they are all presumably aware that D2 is still undergoing some polish. So are the maybe a few hundred people that are using D for hobby projects. They are early adopters, and they know what that entails. I call bogus on the backwards compatibility argument. There's not a lot to be compatible with at this stage. Not compared to what D2 wants to become.
As for Andrei's book using save with the parentheses: If D2 gains traction, I'm sure there will be a second edition of that book. And you already want to have the errata handy when using the book. I don't see what the big deal is, at least not compared to letting this stay in the language forever.
save being a property is a stupid inconsistency. It's easy to fix, the cost is relatively low. The people using D2 now are all part of a community that want D to succeed, as am I. It's a change for the better, which I'm sure most current D2 users would agree with. How hard can it be?

On Monday, 12 December 2011 at 12:24:53 UTC, torhu wrote:
> On 11.12.2011 22:24, Jonathan M Davis wrote:
> ...
>> It was debated some time ago, and it ended up being a property. The fact that
>> save is an action verb and not a noun automatically disqualifies it as a
>> property IMHO, but it was made into a property, and we're pretty much stuck
>> with it at some point. As far as what the function does, I don't think that
>> it's a problem that it's a property, but it's not named like a property, so
>> the situation with regards to save is not ideal, but it's too late now.
>> I really don't get this. When D has 10,000 programmers using it professionally, it's too late. But now it's more like 5 or 10. And they are all presumably aware that D2 is still undergoing some polish. So are the maybe a few hundred people that are using D for hobby projects. They are early adopters, and they know what that entails. I call bogus on the backwards compatibility argument. There's not a lot to be compatible with at this stage. Not compared to what D2 wants to become.
>> As for Andrei's book using save with the parentheses: If D2 gains traction, I'm sure there will be a second edition of that book. And you already want to have the errata handy when using the book. I don't see what the big deal is, at least not compared to letting this stay in the language forever.
>> save being a property is a stupid inconsistency. It's easy to fix, the cost is relatively low. The people using D2 now are all part of a community that want D to succeed, as am I. It's a change for the better, which I'm sure most current D2 users would agree with. How hard can it be?
Furthermore, there weren't even a way to enforce the property syntax until lately, and it's still not enabled by default. If we change it right now, people still have time to adapt before the backwards-compatibility argument even kicks in (no matter how weak it is).

On 12 December 2011 14:24, torhu <no@spam.invalid> wrote:
> On 11.12.2011 22:24, Jonathan M Davis wrote:
> ...
>> It was debated some time ago, and it ended up being a property. The fact
>> that
>> save is an action verb and not a noun automatically disqualifies it as a
>> property IMHO, but it was made into a property, and we're pretty much
>> stuck
>> with it at some point. As far as what the function does, I don't think
>> that
>> it's a problem that it's a property, but it's not named like a property,
>> so
>> the situation with regards to save is not ideal, but it's too late now.
>>>> I really don't get this. When D has 10,000 programmers using it professionally, it's too late. But now it's more like 5 or 10. And they are all presumably aware that D2 is still undergoing some polish. So are the maybe a few hundred people that are using D for hobby projects. They are early adopters, and they know what that entails. I call bogus on the backwards compatibility argument. There's not a lot to be compatible with at this stage. Not compared to what D2 wants to become.
>> As for Andrei's book using save with the parentheses: If D2 gains traction, I'm sure there will be a second edition of that book. And you already want to have the errata handy when using the book. I don't see what the big deal is, at least not compared to letting this stay in the language forever.
>> save being a property is a stupid inconsistency. It's easy to fix, the cost is relatively low. The people using D2 now are all part of a community that want D to succeed, as am I. It's a change for the better, which I'm sure most current D2 users would agree with. How hard can it be?
>
I completely agree. One thing that most excited me about D at this stage,
and buying in as an early adopter is that the developers WILL have the
courage to make breaking changes if they're in the interest of creating a
better language.
I think every opportunity should be taken to make important breaking
changes while the community is as small as it is. If the changes are
reasonably trivial, then surely it doesn't trouble anyone THAT much to
update their code. If they're using D2, surely they know it's still in the
works.