[Issue 10643] Refused const array struct field initialized with void

[d-bugmail at puremagic.com]

https://d.puremagic.com/issues/show_bug.cgi?id=10643



--- Comment #3 from Maxim Fomin <maxim at maxim-fomin.ru> 2013-12-14 07:21:23 PST ---
(In reply to comment #2)
> (In reply to comment #1) 
> > The issue is that void initializer does not disable initialization but fills
> > aggregate member with zero (it also fills data with zeros for types which .init
> > property is not zero).
> 
> Technically, void initialization implies *no* initialization whatsoever:
> 
> //----
> void main()
> {
>     {
>         int i = 5; 
>     }
>     int i = void;
>     assert(i == 5;
> }
> //----

Actually there is difference between void initialization of variable and member
field. In first case it is as you say, but in second case void initialization
means filling data with zero bytes. You may argue that it is incorrect, but
untill the behavior is changed, you are stuck with it.

Anyway, void is irrelevant to the issue, because judjing by issue 11739, you
have something different in mind.

> When a *member* of a struct is declared void, it's value may be padded with
> anything the compiler wishes. Regardless of what the bits are, the value
> remains non-initialized.
> 
> > If you replace void with some number, the code would not
> > still compile, so this is not a specific to void. Also this fails in accordance
> > with change-log.
> 
> I don't understand this answer. "Non"-initialization is *still* initialization
> to T.init, yet that's allowed.

Yes, but this is third case. Why is it relevant here? I think you are just
confuse the discussion.

> > From http://dlang.org/changelog.html#staticfields : "Eventually, they will be
> > deprecated, and then will trigger an error."
> 
> I don't understand why it is not legal to have a const member with an
> initializer. So now it is impossible to do this?
> 
> struct S
> {
>     const(int) i = 5; //default const value
>     this(int n)
>     {
>         i = n; //Override default
>     }
> }
> 
> void main()
> {
>     S s;
>     assert(s.i == 5);
> }

Ok, here is what you really mean (i think). Note, that the code fails with any
initializer (void or some value), so void is irrelevant. Default initialization
is also irrelevant because you have initializer. So, the issue of interest is: 

struct S
{
    const(int) i = void; // or any other initializer
    this(int j)
    {
        i = j;
    }
}

>From changelog: Eventually, they will be deprecated, and then will trigger an
error. Such fields should now be changed to enum or static. Making a field
implicitly static based on whether it is const/immutable and has an initializer
leads to confusion. The static keyword can be used to explicitly make any field
static.

That is why the code is rejected. I would add into rationale additional point:
having initializer and overwriting field is useless because you either know in
beforehand value of a member (and use initializer), or you do not (and set
value in RT).

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------