Proposal: Implicit type conversion for structs

[Bill Baxter]

Maybe you can try to explain this once more in a format of
1. Here's a problem currently faced by developers
2. here's a suggestion for how to fix it
3. heres how my suggestion resolves that problem
4. here's why I think this is the best/only way to resolve the problem.

Reading your proposal, it's not clear what problem you're trying to 
solve to begin with, so it's hard to get excited about the solution. 
It's also difficult for others to offer you alternative solutions to the 
problem, not knowing what the problem is to begin with.

That said, the proposal sounds reminiscent of C++'s overloadable 
(implicit) conversion operators, which have caused me more trouble than 
benefit.  E.g.
     operator float() const { return aFloat; }

Item 5 from Scott Meyer's Effective C++:
"Be wary of user-defined conversion functions
...you usually don't want to provide type conversion functions of *any* 
ilk.  The fundamental problem is that such functions often end up being 
called when you neither want nor expect them to be.  The result can be 
incorrect and unintuitive program behavior that is maddeningly difficult 
to diagnose.  ... In general, the more experience C++ programmers have, 
the more likely they are to eschew type conversion operators."

In C++ you can now label these conversion functions as 'explicit', 
meaning the above would require and explicit cast (i.e. (float)anObject) 
to invoke it, but at that point you might as well avoid the magic syntax 
and just provide a toFloat() method that will be both more obvious to 
readers of the code and easier to find for users of your API trying to 
find that functionality.

--bb

Jaak wrote:
> Hello
> 
> I propose the following extension to structs:
> 
> One can define methods for struct T of the type:
> 
>   T opImplicitConvert(T2 t)
> 
> which allows the implicit conversion of variables of
> type T2 to type T.
> (the name itself is not important, others possibilities:
>  opImpConvFrom, opICast_r, etc.)
> 
> A conversion does no make sense if the types T2 and T
> are the same, as that can cause an infinite chain
> of conversions.
> 
> i.e.   T opImplicitConvert(T t)  is illegal
> 
> 
> We now get opAssign semantics without breaking
> or changing the way assignments currently work.
> 
> Example code:
> 
> struct Vector {
>   float[] elems;
> 
>   ...
> 
>   Vector opImplicitConvert(float[] a)
>   {
>     Vector v;
>     v.elems = a.dup;
>     return v;
>   }
> }
> 
> ...
> 
> Vector u, v;
> 
> // Current system
> u = v;  // Currently OK
> u = [1f 2f 3f]; // ERROR
> 
> // Proposed system
> u = v;  // Still OK
> v = [1f 2f 3f]; // OK, as Vector.opImplicitConvert(float[]) exists
> 
> 
> 
> 
> Some possible enhancements:
> 
> 1. A smarter compiler may be able to figure out conversions chains if
> a direct conversion is not possible.
> I.e.
> 
> MyVector a;
> YourVector b;
> HisVector c;
> 
> 
> // uses Vector.opImpConv(YourVector.opImpConv(HisVector)) if
> // Vector.opImpConv(HisVector) does not exist
> a = c;
> 
> 
> 
> 2. If property syntax can be used to add methods to structs, one can do 
> the following:
> 
> Vector opImplicitConvert(Vector, OtherVector w) {
>   Vector t;
>   t.elems = w.elems;
>   return t;
> }
> 
> // Then, variables of type OtherVector can be implicitly
> // converted to type Vector. This is especially useful if
> // the source implementing the struct Vector is not available.
> 
> OtherVector w;
> v = w; // expands to v = v.opImplicitConvert(w);
> 
> 
> 
> 
> Any comments?
> 
> -
> Jaak