Messing with betterC and string type.

SrMordred patric.dexheimer at gmail.com
Thu Sep 6 16:24:12 UTC 2018


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?








More information about the Digitalmars-d mailing list