I think that cast is binary operation with value and type. And I made groundless patch(I tested with dmdfe and gdc-2.0-dev). This idea break old opCast call and have side effects like allowing "cast(value)". But it support other pattern like "type + value". How about this idea? #sorry for my poor English

val_a op val_b (Example: a + b)
val_a.opfunc(val_b)
val_b.opfunc_r(val_a)

val op type (Example: a + B, cast(B)a)
val.opfunc!(type)()
type.opfunc_r(val)

type op val (Example: A + b)
type.opfunc(val)
val.opfunc_r!(type)()

type_a op type_b (Example: A + B)
type_a.opfunc!(type_b)()
type_b.opfunc_r!(type_a)()

nazo wrote:
> I think that cast is binary operation with value and type. And I made groundless patch(I tested with dmdfe and gdc-2.0-dev). This idea break old opCast call and have side effects like allowing "cast(value)". But it support other pattern like "type + value". How about this idea?
> #sorry for my poor English
> 
> val_a op val_b (Example: a + b)
> val_a.opfunc(val_b)
> val_b.opfunc_r(val_a)
> 
> val op type (Example: a + B, cast(B)a)
> val.opfunc!(type)()
> type.opfunc_r(val)
> 
> type op val (Example: A + b)
> type.opfunc(val)
> val.opfunc_r!(type)()
> 
> type_a op type_b (Example: A + B)
> type_a.opfunc!(type_b)()
> type_b.opfunc_r!(type_a)()


Interesting ideas. I can't see off hand what uses mixing types and expressions in binary operations could have. Do you have any such in mind? Also, doesn't this introduce ambiguities?

Type *val; // Type.opfunc(val) or declaration of ptr to Type?

Allowing

T opCast(T)() {...}

is great. The next step should be making opCast conversions implicit instead of explicit and thereby usable. :)
This also calls for better template specialization methods...

opCast_r is a really interesting idea close to C++ implicit constructors. They should also be implicit to be of much use.

/Oskar

Oskar Linde wrote:
> Interesting ideas. I can't see off hand what uses mixing types and expressions in binary operations could have. Do you have any such in mind? Also, doesn't this introduce ambiguities?
> 
> Type *val; // Type.opfunc(val) or declaration of ptr to Type?
I have no mind but this extend more representation.
I think that this doesn't introduce ambiguities because this section is after semantic analysis.
> Allowing
> 
> T opCast(T)() {...}
> 
> is great. The next step should be making opCast conversions implicit instead of explicit and thereby usable. :)
> This also calls for better template specialization methods...
really. I had forgotten:-(
> opCast_r is a really interesting idea close to C++ implicit constructors. They should also be implicit to be of much use.
> 
> /Oskar
>