On Friday, 13 October 2017 at 13:01:48 UTC, Steven Schveighoffer
wrote:
On 10/12/17 7:57 PM, Q. Schroll wrote:
We have some sort of implicit construction already. Weirdly,
it's reserved for classes. Just look at this:
class C { this(int x) { } }
void foo(C c ...) { }
void main() { foo(0); }
If you put @nogc in front of ctor and functions, the compiler
tells you not to use 'new' in main while you actually don't.
Merely the compiler inserts it for you to complain about it.
Not sure where you put the @nogc.
class C { this(int x) @nogc { } }
void foo(C c ...) @nogc { }
void main() @nogc { foo(0); }
It tells you not to use 'new' while you don't (explicitly, at
least).
What is likely happening is that the call to foo is lowered to
foo(new C(0)). Indeed, using -vcg-ast proves it.
Probably. I don't care -- the compiler should not give me this
error message. I've filed a bug report, but I cannot find it
anymore.
The spec says it can put the class on the stack, but is not
required to.
Exactly. It shouldn't work and doesn't. That's not the problem.
One could propose to extend the three-dots notation to
structs. I don't.
The fact that this is not supported (it isn't, I tried it)
doesn't make any sense.
It tried once, too.
It's likely this hails from a time where classes had ctors and
structs did not, and is just not a feature that anyone cared
about or used.
IMO, it should be extended for structs just in terms of
consistency. But I don't think it would be a high priority.
That would be another consistent solution. Even if we had this
for structs, there is the @nogc argument not to allow it for
classes (the compiler inserts nontrivial things: the heap
allocation).
I'd vote for deprecating the three-dots for classes. Did you
know it exists? Did you use it - like ever? Does anyone depend
on it?
I'm mixed on it. I wouldn't care personally if it was removed,
but it's a feature that may be used somewhere, and there's no
harm in keeping it.
Even extending this to structs does not give you implicit ctor
calls. You can use ... only for the last parameter for obvious
reasons. It's completely different from implicit ctor calls. I
only mentioned that as it is the closest thing in D to implicit
ctor calls.
[snip]
It's a neat idea. I don't see why we would need to remove the
typesafe variadics to allow this to work.
You don't. I mentioned it as it is somehow implicit ctor call.
It *really* would be nice though, to allow annotations on
parameters. The @implicit(1) stinks. Would look much better as:
proto_goo(int v, @implicit S s, bool b);
I tried that, too, and failed because of that. (I'd even assume
anyone would, because it'd be the obvious way to want it.) This
is another reason to allow that.
Where you may run into trouble is if there is ambiguity (for
instance 2 implicit parameters could match the potential
arguments in different ways).
How? I only accept *one* parameter. Ctors with more than one
parameter are disallowed. One could allow those which can be
called with one parameter because they fill the rest with default
values. I didn't for the sake of an easier implementation. It's a
first sketch, a proof of concept.
Another option is to not worry about tagging which parameters
would be implicit, and go only on the fact that types in the
parameter list have @implicit constructors when you call
implicitOverloads.
There are two reasons against it.
1. implicitOverloads would search much more for nothing.
2. You'd add implicit overloads the author of the function
maybe wouldn't want.
You can think of my system as offer and acceptance. You need
both. @implicit ctors do nothing for themselves the same way
@implicit(1) does nothing if the targeted type has nothing to
offer. That's on purpose to make implicit ctor calls as
transparent as possible. Walter didn't want implicit construction
because it is non-transparent. Under these circumstances, it has
good chances to be accepted for Phobos.
