On Fri, May 17, 2013 at 10:54 AM, Don Clugston <dclugston@gmail.com> wrote:Yes, I have already been corrected and sorry for choosing wrong term.
> You're talking about a struct static initializer. That is not the same as a
> constructor.
What essential though is that both constructor and struct literal
initializer allow to initialize immutable struct members.
Because there is no constructor-like entity for local scope.
> You cannot change the value of a local-scope const variable, once it has
> been initialized.
If this was not changed together with struct/class changes, it sounds
>
> You cannot change the value of a module-scope const variable, once it has
> been initialized. Not even in a constructor.
like yet another bug.
Consistency is not about behavior of single feature (const initialized
> Up to now:
> You cannot change the value of a struct member const variable, once it has
> been initialized. Not even in a constructor.
>
> I think the consistency argument acts AGAINST this new behaviour.
variable), it is more about what place it takes in the overall type
system. If const variable behaves like this, it is no different from
"enum" and you have two ways to do the same thing without a single way
to do what I am expecting from const variable.
And what if you want to have BOTH default CTFE initialization and
>> * They have both compile-time initialization and run-time one. First
>> is T.init, second is T(...). Needing both is a perfectly valid need
>> from the programmer, especially with generic code in question.
>
>
> I think that the reason that having both an initializer and a constructor
> appears desirable, is actually as a workaround for the lack of struct
> default constructors.
> If we really need a solution for that, we should consider doing something
> like allowing struct default constructors, but requiring them to be
> CTFEable.
additional initialization based on some run-time data?
It is not more confusing than the fact that immutable is mutable in a
> Rather than allowing const members to be initialized twice, which is
> confusing for both the programmer and the compiler to understand. (Both
> compiler and programmer would need to inspect all of the code looking for a
> possible constructor, in order to know if a const initializer is
> meaningful).
constructor. Actually, most confusing part here is that this bug was
not fixed 20-30 compiler release ago, it never made sense.
Yes and I fully agree that this is a horrible breaking change. That is
> But in any case, the situation is that with this beta, code which used to
> declare a manifest constant in a struct, now allocates memory in each
> struct, and each copy of that memory contains the same value. Those two
> behaviours have nothing in common, so *all* existing cases will need to be
> modified. (basically by adding 'static' to the front of each one).
> We can't silently break code in this way.
why I suggested to use "-transition=XXX" as a default approach to
simplify such situations. And eternal gratitude goes to Kenji who has
actually implemented it. I am completely on your side when it comes to
silent breakages, only thing I argue is that old behavior was right.
What do you find unacceptable/inconvenient in "-transition=XXX" approach?
> Therefore:
> We should make non-static const/immutable members with initializers into an
> error in this release. Then all existing cases will have 'static' explicitly
> added to them. Up to now it's been implicitly added, which is an unnecessary
> feature and somewhat surprising behaviour.
_______________________________________________
dmd-beta mailing list
dmd-beta@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-beta