Implicit Constructors

[Steven Schveighoffer]

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.

What is likely happening is that the call to foo is lowered to foo(new 
C(0)). Indeed, using -vcg-ast proves it.

The spec says it can put the class on the stack, but is not required to.

> 
> 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'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.

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

> 
> (If you don't want to read it all: The examples may be expressing enough.)
> 
> The main point of this post is a library solution to implicit 
> constructor calls. The implementation is very conservative: A double 
> handshake; not the constructors must be annotated with @implicit, the 
> functions which want to allow being called with a constructor parameter 
> must explicitly state that (these functions are called "receiving" 
> functions). @implicit constructors must have exactly one parameter (no 
> defaulted additional ones) and a receiving function has an annotation 
> @implicit(i) where i is the index of a parameter for which it will be 
> allowed to plug in a constructor argument of its type. Sounds 
> complicated? See an example.
> 
>      struct S
>      {
>          import bolpat.implicitCtor : implicit;
>          long s;
>          @implicit this(int x)  { s = x; }
>          @implicit this(long x) { s = x; }
>          this(bool x) { s = x ? 0 : -1; }
>      }
> 
> This is all that you need from the one side. Now the receiver side.
> 
>      import bolpat.implicitCtor : implicit, implicitOverloads;
> 
>      long proto_goo(int v, S s, bool b) @implicit(1)
>      {
>          import std.stdio : writeln;
>          writeln("goo: call S with value ", s.s);
>          return b ? v : s.s;
>      }
>      void proto_goo(char c) { } // no @implicit(i) ==> will be ignored
> 
>      mixin implicitOverloads!("goo", proto_goo); // generates goo
> 
>      assert(goo(1, 2, false) == 2);
> 
> It also works for members. See:
> 
>      struct Test
>      {
>          int proto_foo(int v, S s) @implicit(1)
>          {
>              import std.stdio : writeln;
>              writeln("foo: call S with value ", s.s);
>              return v;
>          }
> 
>          void proto_foo(char c) { } // ignored
> 
>          mixin implicitOverloads!("foo", proto_foo);
>      }
> 
> What to do further? Make @implicit take more than one argument. I'm 
> working on it. This is just a first taste. And for Stefan Koch, thanks 
> to static foreach, one can safe so many templates.
> 
> tl;dr the implementation is here:
> https://github.com/Bolpat/dUtility/blob/master/bolpat/implicitCtor.d

It's a neat idea. I don't see why we would need to remove the typesafe 
variadics to allow this to work.

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);

Where you may run into trouble is if there is ambiguity (for instance 2 
implicit parameters could match the potential arguments in different ways).

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.

-Steve