On Wednesday, May 15, 2013 16:11:03 Don Clugston wrote:
> > You kind of propose that "const int" to be a completely different type depending on initialiser. It is horrible.
> 
> I have not said that. I've asserted that const member with an initializer,
> when inside a struct, is ALWAYS a bug.
> I agree that we need to get rid of the existing behaviour. But I argue it
> should simply be an error, rather than replacing it with a misfeature.

Indeed. It really makes no sense to have const or immutable members in a struct. You simply render the struct completely useless under a variety of circumstances, because it can't ever be reassigned. It's one thing to create a const or immutable instance of a struct. It's quite another to have a single member which is const or immutable. You might as well just make such a member static.

Now, as useless as it is, it's perfectly consistent with the rest of the language to have const or immutable members actually be part of the struct layout rather than effectively being treated as implicitly static, and the old behavior is definitely inconsistent with the rest of the language. But given how this will silently break who knows how much code, it's a terrible change. It would be far better to just disallow it.

- Jonathan M Davis
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/15/2013 4:27 AM, Don Clugston wrote:
> This absolutely must not be released in this form.
> This has a silent, massive breaking change --
> struct  S { const int x = 7; }
> Previously, x was just a manifest constant. Now, S now has an int inside every instance.
> It's OK to turn that into an error. It's not OK to silently change the meaning of existing code.
> Especially in such a radical manner.
>

As I recall, there was a loong discussion about this, and I had thought everyone agreed.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/15/2013 7:39 AM, Andrei Alexandrescu wrote:
> On 5/15/13 10:01 AM, Don Clugston wrote:
>> I think the new behaviour is a misfeature, and nothing more. It makes no
>> sense to store a value in each struct, when the value is exactly the
>> same every time.
>
> Consider:
>
> struct A
> {
>   const int x = 7;
>   this(int y) { x = y; }
> }

I think that should not be allowed, because x is const and is being initialized twice.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/15/13 2:00 PM, Walter Bright wrote:
>
> On 5/15/2013 7:39 AM, Andrei Alexandrescu wrote:
>> On 5/15/13 10:01 AM, Don Clugston wrote:
>>> I think the new behaviour is a misfeature, and nothing more. It makes no
>>> sense to store a value in each struct, when the value is exactly the
>>> same every time.
>>
>> Consider:
>>
>> struct A
>> {
>> const int x = 7;
>> this(int y) { x = y; }
>> }
>
> I think that should not be allowed, because x is const and is being
> initialized twice.

There's a default and there's an explicit initializer. We could disallow that but it wouldn't be terribly sensible.

Andrei

_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/15/2013 11:30 AM, Andrei Alexandrescu wrote:
> On 5/15/13 2:00 PM, Walter Bright wrote:
>>
>> On 5/15/2013 7:39 AM, Andrei Alexandrescu wrote:
>>> On 5/15/13 10:01 AM, Don Clugston wrote:
>>>> I think the new behaviour is a misfeature, and nothing more. It makes no
>>>> sense to store a value in each struct, when the value is exactly the
>>>> same every time.
>>>
>>> Consider:
>>>
>>> struct A
>>> {
>>> const int x = 7;
>>> this(int y) { x = y; }
>>> }
>>
>> I think that should not be allowed, because x is const and is being
>> initialized twice.
>
> There's a default and there's an explicit initializer. We could disallow that but it wouldn't be terribly sensible.

I believe it was disallowed in earlier D2 versions. If I saw such code in a project, I'd find it awfully suspect, not sensible.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

In a struct with multiple constructors, it could make sense to give an immutable field a default value.


On Thu, May 16, 2013 at 5:02 AM, Walter Bright <walter@digitalmars.com>wrote:

>
> On 5/15/2013 11:30 AM, Andrei Alexandrescu wrote:
>
>> On 5/15/13 2:00 PM, Walter Bright wrote:
>>
>>>
>>> On 5/15/2013 7:39 AM, Andrei Alexandrescu wrote:
>>>
>>>> On 5/15/13 10:01 AM, Don Clugston wrote:
>>>>
>>>>> I think the new behaviour is a misfeature, and nothing more. It makes
>>>>> no
>>>>> sense to store a value in each struct, when the value is exactly the
>>>>> same every time.
>>>>>
>>>>
>>>> Consider:
>>>>
>>>> struct A
>>>> {
>>>> const int x = 7;
>>>> this(int y) { x = y; }
>>>> }
>>>>
>>>
>>> I think that should not be allowed, because x is const and is being initialized twice.
>>>
>>
>> There's a default and there's an explicit initializer. We could disallow that but it wouldn't be terribly sensible.
>>
>
> I believe it was disallowed in earlier D2 versions. If I saw such code in a project, I'd find it awfully suspect, not sensible.
>
> ______________________________**_________________
> dmd-beta mailing list
> dmd-beta@puremagic.com
> http://lists.puremagic.com/**mailman/listinfo/dmd-beta<http://lists.puremagic.com/mailman/listinfo/dmd-beta>
>

On 5/15/13 3:02 PM, Walter Bright wrote:
> I believe it was disallowed in earlier D2 versions. If I saw such code
> in a project, I'd find it awfully suspect, not sensible.

On the contrary, examples abound. Consider:

class Image {
    const double scalingFactor = 1.0; // no scaling
    this(double sf) {
        scalingFactor = sf;
        ...
    }
    ...
}

What is suspect about this? I have about five others without even needing to think that hard.


Andrei
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On Wed, 15 May 2013 15:07:13 -0400
Andrei Alexandrescu <andrei@erdani.com> wrote:

> On 5/15/13 3:02 PM, Walter Bright wrote:
> > I believe it was disallowed in earlier D2 versions. If I saw such code in a project, I'd find it awfully suspect, not sensible.
> 
> On the contrary, examples abound. Consider:
> 
> class Image {
>      const double scalingFactor = 1.0; // no scaling
>      this(double sf) {
>          scalingFactor = sf;
>          ...
>      }
>      ...
> }
> 
> What is suspect about this? I have about five others without even needing to think that hard.
> 

I had almost been convinced of the opposite, but I think you're absolutely right:

Being able to specify at runtime an instance-specific value which isn't allowed to change again during the object's lifetime (not even from within the same module) does indeed seem quite useful. I'm certain I've come across cases in the past where I'd have liked that, but just wasn't sure how to do it in a compiler-enforced way.

FWIW, I think the compiler flag Jason and Kenji suggested sounds like
the most sensible way to deal with this.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

Andrei Alexandrescu, el 15 de May a las 15:07 me escribiste:
> On 5/15/13 3:02 PM, Walter Bright wrote:
> >I believe it was disallowed in earlier D2 versions. If I saw such code in a project, I'd find it awfully suspect, not sensible.
> 
> On the contrary, examples abound. Consider:
> 
> class Image {
>     const double scalingFactor = 1.0; // no scaling
>     this(double sf) {
>         scalingFactor = sf;
>         ...
>     }
>     ...
> }
> 
> What is suspect about this? I have about five others without even needing to think that hard.

I think it make more sense to put the default in the constructor argument instead of in the member variable declaration. In that case is pretty clear, but if the member declaration is far from the constructor, one could easily assume scalingFactor is always 1.0.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Esta desenchufada la internet de ese televisor?
	-- Osvaldo Lucarella
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta

On 5/15/2013 12:07 PM, Andrei Alexandrescu wrote:
> On 5/15/13 3:02 PM, Walter Bright wrote:
>> I believe it was disallowed in earlier D2 versions. If I saw such code
>> in a project, I'd find it awfully suspect, not sensible.
>
> On the contrary, examples abound. Consider:
>
> class Image {
>     const double scalingFactor = 1.0; // no scaling
>     this(double sf) {
>         scalingFactor = sf;
>         ...
>     }
>     ...
> }
>
> What is suspect about this? I have about five others without even needing to think that hard.

It means I can't read the code and easily determine what that const value is, even though it is explicitly initialized with a value.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta