Lack of conversions when passing parameters

[bachmeil]

Carl Sturtivant has posted on the D forum about "the lack of conversions when passing parameters". If you have

void foo(Variant x) {
  writeln(x.type);
}

you have to call it like this

foo(Variant(2.5));

rather than

foo(2.5);

It's not just Variant, it's also a struct like

struct Foo {
  double x;

  this(string s) {
    x = s.to!double;
  }
}

void foo(Foo y) {}
// Fails
foo("4.2");

I've always disliked this verbosity. Would you be open to an addition to the standard library that let you do something like this

Overload!(foo, Foo);

that creates a function like this

void foo(T)(T y) {
  foo(Foo(y));
}

Of course it would need to work with an arbitrary number of parameters with type Foo.

[IgorDeepakM]

If you look at the roadmap, implicit cast and Implicit construction seems to be on the agenda.

https://dpldocs.info/opend/roadmap.html

These are features in C++ that I do like and I haven't had any particular problems with them. I have followed the thread on dlang and it is true that I don't really have the overloading search priority in my head, neither in C++ or D but that hasn't been much a problem. Also if there is a problem you can do an explicit cast anyway. C++ usually politely tells you when there is an ambiguity.

In general I'm open for these changes.

[bachmeil]

It says "Implicit construction (at least on return values)" and I suspect doing it for return values is quite a bit easier than for the arguments to the function. The thing I like about the library solution is that you wouldn't run into issues with overloading. In other words, if you have

void foo(Foo y) {}
void foo(Bar y) {}

and the conversion works for both Foo and Bar, it still does the right thing, with no additional complication to the language and no error message.

[adamdruppe]

Yeah, for function params and return values in particular it is kinda annoying and I'd like to do something about it. Also there's been some experimentation on an opImplicitCast that might be interesting. I'd love for a dynamic var type to feel really dynamic if we do it all right.

[bachmeil]

some experimentation on an opImplicitCast

I really like that idea.

[adamdruppe]

On terminology I define implicit conversion and implicit construction as slightly different.

If type B has opImplicitCast to A, that's implicit conversion.

If type A has an implicit constructor that accepts type B, that's implicit construction.

D has limited case of both: alias this provides implicit conversion, and a foo(A...) function..... well.... that's kinda implicit construction but you have to overload a function to provide it so only somewhat. D's story on implicit construction is weak.

I agree that C++ went too far in making things implicit unless you opt out... but I think D went too far in not allowing it at all. I'd rather just make an implicit keyword to opt into it.

[quickfur]

An important question is where this implicit keyword would be placed.

If you allow it in the ctor, then implicit conversion will "infect" everything that uses that type by default. I.e., even code that didn't ask for it will get it (all it takes is for the ctor author to add implicit to the declaration, and all downstream code will inherit the behaviour). This may or may not be a good thing.

If you allow it only in a function's parameter list, it would allow implicit conversion when passing arguments -- so individual functions can opt in or not -- but not elsewhere. I.e. code that didn't explicitly ask for it won't get it silently. This isn't as big a limitation as it seems: for assignments and construction, ctors and opAssign should have already taken care of any convenience of receiving arbitrary compatible types.

[adamdruppe]

I was thinking the constructor because on the function definition you can simply offer an overload to get the same result for the user.

[adamdruppe]

Though you know, offering an overload when there's multiple args isn't so simple anyway...