On Monday, 5 June 2017 at 00:51:15 UTC, Jonathan M Davis wrote:
On Monday, June 05, 2017 00:16:15 Mike B Johnson via
Digitalmars-d-learn wrote:
On Sunday, 4 June 2017 at 23:39:11 UTC, Jonathan M Davis wrote:
> On Sunday, June 04, 2017 22:52:55 Mike B Johnson via
>
> Digitalmars-d-learn wrote:
>> [...]
>
> Aside from whatever implicit conversions are built into the
> language, the only way to define an implicit conversion in D
> is via alias this on a user-defined type, which then tells
> that type that it can convert to whatever type the result of
> the alias this is. e.g. if you have
>
> [...]
I might be able to change the enum, I assume you mean
something like
enum myenum : S { }
where S is the struct that implicitly converts?
Yes.
However, be aware that you can currently only define one alias
this per type. So, the rest of the code will then need to be
able to deal with the fact that the enum is a struct that
implicitly converts to VARIANT and does not implicitly convert
to int. So, if you're just passing the enums around and
comparing them, you're fine, but if you need to treat them as
ints somewhere, then you'll need to provide an explicit
conversion (via overloading opCast or by creating a specific
function for it or just exposing a member with the int value or
whatever), and that could get annoying in the same way that
you're annoyed about the VARIANT issue right now.
But if you don't actually need to treat the enum as an int, and
you can make it a struct that implicitly converts to VARIANT
instead, then that will fix your VARIANT conversion problem.
- Jonathan M Davis
Well, I do need to to treat it as an int at times and opCast only
works with cast. While I could set it up to do a cast(VARIANT),
which is better than nothing, I'd get same result as to!VARIANT,
which is shorter and effectively the same.
When will we get multiple alias this? all I need is two?
Hell, why not make alias this an "overloadable" function similar
to opCast and such?
