Messing with betterC and string type.

[Adam D. Ruppe]

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