12/1/2012 1:38 AM, Jonathan M Davis пишет:
On Friday, November 30, 2012 23:34:04 Dmitry Olshansky wrote:
11/30/2012 3:31 AM, Jonathan M Davis пишет:
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.
If
auto t = T();
works then you don't have to care whether the type has a static opCall or not.
You get the most valid default-constructed object that there is (or at least,
the closest thing that there is to a default-constructed object). If that's
init, then it's init. If it's static opCall, then it's static opCall. I don't
want to have to care which it is. Also, if I see
T t;
I'm likely to think that was supposed to be initialized, but the programmer
forgot, whereas with
Then I'd say
T t = T.init;
for when you want explicitness.
Other then this I've come to rely on
T t;
being default constructed and not rising an eyebrow.
It's only in context such as these 3 lines :
T x = blah;
U y = bleh;
W w;
That I'd think w == T.init might be unintended.
auto t = T();
it's clear that that it was intended to be initialized to whatever T() is (be
it T.init or the result of a static opCall), and it's clear that the
programmer didn't forget to initialize it.
Either way my final proposal doesn't remove it. In short it goes as follows:
- allow 0-arg constructors for consistency and cross-cutting issues
(like all default args ctor)
- use a default one (as is done with per-field constructors) if none or
user defined match. The default will blit object with T.init.
It'd let static opCall be there as is. It will just put them in the same
overload set as constructors.
--
Dmitry Olshansky
