I'm most of the time exploring the betterC lands
and was thinking about custom strings, and how to convert D into
D-betterC
hmm I wonder...
struct String{}
alias string = String;
string x = "test";
//cannot implicitly convert expression "test" of type string to
String
ok then...
struct String{
this(string x){}
}
//constructor app.String.this(String x) is not callable using
argument types (string)
Ok now things got weird.
...
this(String x){}
//same error.
Ok the string is a String but not a string... what monster I
created?
How to tame this chimera? templates off course
this(T)(T t){}
//compiles!!
Now some true utility:
string x = "test";
x = x ~ x;
//incompatible types for (x) ~ (x): both operands are of type
String
as expected:
...
String opBinary(string op, T)(T other)
{
return String();
}
//incompatible types for (x) ~ (x): both operands are of type
String
hmmm, whats happening?
x.opBinary!"~"(x);
//template app.String.opBinary cannot deduce function from
argument types !("~")(String), candidates are:
//source\app.d(9,12): app.String.opBinary(String op, T)(T
other)
Oh, it must be the string is not string chaos that I started.
String opBinary(alias op, T)(T other)
{
return String();
}
//compiles!!
Ok, so then *maybe* I can transform D normal code using 'string'
to D-BetterC only with aliasing my custom struct.(off course,
besides all other problems that may emerge)
My question is, i´m breaking something else, or this could be a
valid approach?
