<div dir="ltr"><div><div><div><div><div>> If const variable behaves like this, it is no different from<br>
"enum" and you have two ways to do the same thing without a single way<br>
to do what I am expecting from const variable.<br><br></div><div>No!!!!! You've got a fundamental misunderstanding here. Both those statements are wrong.<br><br>A const member in a struct, that does not have an initializer, has ALWAYS been stored in the struct (even in D1).<br>
</div><div>The issue is what to do with const members that have initializers.<br></div><div>Historically, they've been treated as manifest constants. There's a good argument that that is wrong.<br></div><div>But treating them as a value stored in every struct, where every value is the same, is even worse.<br>
</div><div>I think we just have to make it illegal to provide an initializer on a const member.<br><br>> And what if you want to have BOTH default CTFE initialization and<br>
additional initialization based on some run-time data?<br><br></div><div>Then you have a flaw in your thinking. That doesn't make sense.<br></div>And, I still do not believe that there is a single valid use case for the new behaviour.<br>
</div><br></div><div>Here's the reason:<br></div>If you can provide an initializer for a struct member, that is the same for all instances of that struct, and you will never change that member, it shouldn't be a member of the struct in the first place. It should be static const or an enum value.<br>
</div>If however you're going to change the member in the constructor, based on a runtime value, the initializer is meaningless and shouldn't have existed.<br><br><div><br>> What do you find unacceptable/inconvenient in "-transition=XXX" approach?<br>
<br></div>Because 100% of existing cases must be changed.<br><br></div><div>This isn't even like static variables becoming shared by default, where some of the cases needed to change to __gshared but the rest were OK with becoming shared.<br>
 Every existing usage becomes a bug. There are no exceptions.<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 17 May 2013 10:29, Михаил Страшун <span dir="ltr"><<a href="mailto:m.strashun@gmail.com" target="_blank">m.strashun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, May 17, 2013 at 10:54 AM, Don Clugston <<a href="mailto:dclugston@gmail.com">dclugston@gmail.com</a>> wrote:<br>

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