11/30/2012 3:31 AM, Jonathan M Davis пишет:
On Thursday, November 29, 2012 20:27:32 Dmitry Olshansky wrote:
11/29/2012 7:24 AM, Walter Bright пишет:
On 11/29/2012 4:47 AM, monarch_dodra wrote:
On Sunday, 25 November 2012 at 16:47:08 UTC, Dmitry Olshansky wrote:
Thoughts?
I don't know about "killing" T(), but I think there *needs* to be an
(easy) mechanism to declare ***and*** run-time initialize an object, in
a single and comprehensive line.
I had proposed something 2 months ago here:
http://forum.dlang.org/thread/bvuquzwfykiytdwsq...@forum.dlang.org
The proposal wasn't perfect, but still. We need to figure something
out...
The original idea is that there should be *no such thing* as default
construction of a struct as being anything other than T.init. The
default construction of a struct should be a compile time creature, not
a runtime one.
Okay let it be. I'm not against having a defined blank default
constructed object.
Just don't make T() mean it, please!
I'm all for T() meaning T.init if T doesn't have a static opCall, but T()
shouldn't be guaranteed to be T.init. I'd very much like to see code like
auto t = T();
to continue to work regardless of whether T has a static opCall or not.
And what you'd expect 't' to be then? And why such code is useful
anyway? The only sane way I see is to make it an explicit call of 0-arg
constructor then one can safely assume:
1. t is of type T
2. t is properly constructed and not some invalid state like T.init may be
Currently with opCall it could be anything otherwise it ends up T.init
or compiler error if T is a built-in type.
But it
should be able to have a static opCall, and T() should work if it doesn't have
one. Assuming that T() means T.init makes no sense.
Why in the nine hells we have static opCall to begin with?
Probably to workaround 0-argument ctor situation. I haven't seen a
better or at least sensible use case. Yet it has great potential for abuse.
(and the fact that compiler picks opCall first (static or not) instead
of constructor doesn't help matters much)
--
Dmitry Olshansky
