11/25/2012 9:25 PM, Timon Gehr пишет:
On 11/25/2012 05:47 PM, Dmitry Olshansky wrote:
After killing this ugly craft the suggestion is to, of course,
introduce 0-argument constructors.
I think it should be done, but then it is even less clear how .init
should work.
I suppose that T.init is the blank object, that is composed of
respective initial values of its fields. Initial value is the one
specified during declaration of a field or .init of its type.
You mean the more or less working @disable this(); ?
That might need extra consideration.
static opCall can't prevent introduction of 0-arg constructor as the
compiler already has to disambiguate between the static opCall and the
ctor. (BTW which one wins?)
It does not disambiguate.
I think constructors and static opCall should just overload against each
other,
+1
I can't think of anything more logical then to do just that.
The current behaviour in case there are both opCall and constructors is
to attempt to pick opCall in case the number of arguments is zero and
the constructors otherwise.
...
Thoughts?
1. is valid.
2./3. are examples of insufficient template constraints.
Agreed. The point of second however was mostly about built-ins not
having this way of default construction. Thus T() is quite brittle in
generic code (if the default construction is implied).
If the suggestion is to get rid of the built-in struct 0-arg default
constructor iff the user provides his own constructors, as is done with
the more than 0-arg default constructors, then I fully agree.
Indeed, I haven't thought of automatically provided per-field
constructors. I like your suggestion to do the same with 0-arg ones -
provided automatic one returning T.init. Should be more consistent and
even backwards compatible I guess.
--
Dmitry Olshansky
