[dmd-beta] dmd 2.064 beta take 2

[Don Clugston]

> * structs always have constructors. So this snippet is wrong:
> >   struct S
> >   {
> >       immutable int c = 123; // This should be static, compiler issues
> error
> >       // No constructor
> >   }
> In fact, S has constructor. All structs have constructor with
> parameter count that matches member field count. And judging only by S
> definition you can't ever possibly say if "c" will be the same in all
> S instances or not.
>

You're talking about a struct static initializer. That is not the same as a
constructor.

> Second, it is consistent because it stays the same both for
struct members and local variables. This is much more important than
prohibiting something based on use case approach.

It is inconsistent with module variables.

const int x = 7;
static this()
{
   x = 5;
}

You cannot change the value of a local-scope const variable, once it has
been initialized.

You cannot change the value of a module-scope const variable, once it has
been initialized. Not even in a constructor.

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.

And so I strongly disagree with this:

* 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.
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).

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.

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.

What we actually want the behaviour to be in the long term can be discussed
later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-beta/attachments/20130517/9ff7cf87/attachment.html>