On Friday, 7 September 2018 at 13:58:41 UTC, Jonathan M Davis
wrote:
If we had implicit construction in D but only allowed one level
of conversion (e.g. String could be implicitly constructed from
a const(char)[], but a type that implicitly converted to
const(char)[] couldn't be used to construct a String), maybe it
would be sane enough.
Perhaps. I'd actually be kinda ok (just kinda tho) even if it
only allowed implicit construction from built-in literals, and
only if it is explicitly marked as an implicit ctor.
The main use cases I'd care about are:
void foo(LibraryAAType x) {}
foo(null); // impossible right now, but works with built-ins
void bar(LibraryStringType x) {}
bar(null);
bar("whatever");
And similar. Actually constructing from a variable isn't that
important:
string s = "";
bar(s); // I can live with this being an error
BUT, that said, if we can have it, I'd still appreciate it:
string s = "";
void baz(Variant b) {}
baz(s); // would be nice!
Just, indeed:
struct S {
string s;
alias s this;
}
struct Y {
@implicit this(string s) {}
}
void foo(Y y) {}
S s;
foo(s);
Should that compile? ...eeeh, I can see the argument for yes, I
actually think the implementation will be easier to make it work,
since it follows pretty simple rules (foo(s) didn't work,
automatically try foo(s.s), find it does work, carry on), but I
am totally - totally - ok with saying no to that.
But, what is an absolute must for me: implicit construction MUST
be opt in on the constructor. THAT is the mistake C++ made in my
eyes: they made `explicit` the keyword to turn it off, when they
should have made `implicit` the keyword to turn it on.
And as Kagamin pointed out, you can always create a helper
function with a really short name to call the constructor if
you want to.
you can also do it with a template:
s!"my new string"
which has a few potential optimization benefits, especially if it
needs some kind of processing. (though I would also note it can
be a pessimization cuz the compiler will build the string into
symbol names and not discard them...)
But for replacing a built in, it is still nice if `null` actually
works, and implicit construction is kinda a must there. (Of
course, that's the reasoning that led C++ down its path too -
making std::string work with char*...)
