[dmd-beta] dmd 2.064 beta take 2

[Maxim Fomin]

2013/5/17 Don Clugston <dclugston at gmail.com>

>
> > And what if you want to have BOTH default CTFE initialization and
> additional initialization based on some run-time data?
>
> Then you have a flaw in your thinking. That doesn't make sense.
> And, I still do not believe that there is a single valid use case for the
> new behaviour.
>
> Here's the reason:
> 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.
> 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.
>

Actually the original idea (general, not const specific) makes sense: one
may can  set correct type default value only at runtime, however it is not
possible officially (you can but it is against the spec which mandates that
default type value is fixed).

In such case a user does not care about CT initialization, only about
runtime one, but CT happens in any case. The fact that D does not allow to
reset default value of a struct at runtime is limiting because it forces to
make (and later to ensure that) in each place where struct is used there is
runtime initializer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20130517/d12f003a/attachment-0001.html>