Proposal: Implicit type conversion for structs

[Jaak]

Bill Baxter wrote:
> Maybe you can try to explain this once more in a format of
> 1. Here's a problem currently faced by developers

The main idea is achieving transparent interoperability of types.
When two types are compatible (defined by the existence of suitable 
conversion functions) one can use them as if they are the same type and 
all the magic happens in the background.
For example:

VectorTypeA a;
VectorTypeB b1, b2;
a = b1 + b2;

And as a side effect one gets effects similar to having an overloadable 
opAssign operators without changing assignments that currently compile.
i.e. Vector v = [1f, 2f, 3f]

> 2. here's a suggestion for how to fix it
> 3. heres how my suggestion resolves that problem

Its, basically a way of specifying implicit conversions between types. 
Structs (or arrays using property notation) define a function which 
converts from one type to another:
TO opIConvert(FROM what){...}

If a suitable function exist, it gets called in cases when type TO is 
expected and type FROM is given.

(more details in parent post)

> 4. here's why I think this is the best/only way to resolve the problem.

Well... I was hoping someone in here can point me to a better solution 
if one exists.

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

Aah sorry, I hope this post clarifies things a bit.

> 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; }

It my seems like my proposal is a reversed version of this. I.e. the 
conversion operators are defined in the target type instead of the 
source type (because overloading based on return type is not allowed).

> 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."

I have no experience of this, but i can see how automatic invisible 
function calls all over the place can complicate debugging.
But.... it would still be nice to have the option.

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

Any explicit declaration of intent would sort of defeat the purpose of 
the proposal. The aim of which is mainly to make using different types 
together less verbose (and get opAssign functionality). Anyway, its not 
a dealbreaker, just on my wishlist.

> 
> --bb