www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Make enum auto castable

reply Mike B Johnson <Mikey Ikes.com> writes:
I am dealing with some COM stuff and some functions use VARIANT, 
which can hold an enum.

Instead of having to manually convert the enum(and for that 
matter, other things) to VARIANT, is it possible to have them 
automatically converted?

This is because an enum is always convertible to a VARIANT but 
not the other way around. So, when a enum is passed to a function 
accepting a VARIANT, it should just work. Overloading is not an 
option.
Jun 04 2017
next sibling parent Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Sunday, 4 June 2017 at 22:52:55 UTC, Mike B Johnson wrote:

 I am dealing with some COM stuff and some functions use 
 VARIANT, which can hold an enum.

 Instead of having to manually convert the enum(and for that 
 matter, other things) to VARIANT, is it possible to have them 
 automatically converted?

 This is because an enum is always convertible to a VARIANT but 
 not the other way around. So, when a enum is passed to a 
 function accepting a VARIANT, it should just work. Overloading 
 is not an option.


Not sure if this breaks your requirement but you could generate 
overloads or rather templated version of your variant accepting 
function  with a mixin that introspects on functions with a 
certain uda in the module.  See excel-d for an example.
Jun 04 2017
prev sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Sunday, June 04, 2017 22:52:55 Mike B Johnson via Digitalmars-d-learn 
wrote:

 I am dealing with some COM stuff and some functions use VARIANT,
 which can hold an enum.

 Instead of having to manually convert the enum(and for that
 matter, other things) to VARIANT, is it possible to have them
 automatically converted?

 This is because an enum is always convertible to a VARIANT but
 not the other way around. So, when a enum is passed to a function
 accepting a VARIANT, it should just work. Overloading is not an
 option.


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

struct S
{
    int x;
    alias x this;
}

then S can implicitly convert to int, and when it does, the value of x is
used (alternatively, a member function could be used, in which case, the
result of the member function would be used as the result of the
conversion). So, that allows you to tell how to convert a type _to_ another
type, but it does not allow you to convert _from_ another type. So, if
you're implicitly converting from type A to type B, it will work if type A
has been told how to convert to B, but there is no way for B to say that an
A can be converted to a B. Only A can define the conversion.

So, if you have control of the definition of the base type of the enum, then
you can define an alias this on it to convert to a VARIANT, but if you don't
have control over the definition of the base type of the enum (e.g. if it's
int, as is the default), then you're out of luck. And if you're dealing with
COM, then I'm guessing that your enum has a base type of int, and you
obviously don't control the definition of int, so you can't add an alias
this to it.

So, if you can't change the enum, and you can't change the function that
you're calling, then you'll have to insert something in between - be it a
conversion function, an explicit construction of VARIANT with the enum, or
some kind of wrapper function around the one that you're calling. But unless
the enum itself knows how to implicitly convert to a VARIANT thanks to alias
this, there is no implicit conversion.

std.typecons.Nullable has this sort of problem, which has historically
forced folks to do stuff like Nullable!int(42) when passing the actual type
to a function that accepts a Nullable wrapper around the type, which is
pretty annoying. Recently, a nullable function was added to std.typecons
which uses IFTI to infer the type of the Nullable

auto nullable(T)(T t)
{
    return Nullable!T(t);
}

and then you could pass nullable(42) instead of Nullable!int(42), so it's
more user-friendly, but it still requires an explicit conversion unless you
overload the function. It's a downside to D's stricter approach to implicit
conversions.

- Jonathan M Davis
Jun 04 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
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?
Jun 04 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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
Jun 04 2017
next sibling parent reply Mike B Johnson <Mikey Ikes.com> writes:
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?
Jun 04 2017
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Monday, June 05, 2017 01:12:20 Mike B Johnson via Digitalmars-d-learn 
wrote:

 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?


I don't know when we're getting multiple alias thises. TDPL talks about it
being a thing, and the spec claims that it's a thing, but until someone
implements it, we won't have it, and it hasn't been a priority for Walter.
IIRC, someone tried to implement it at one point, but I don't know where
that went. There was a thread in the main newsgroup a couple of months ago
about how to simulate multiple alias thises, so you might want to check that
out:

https://forum.dlang.org/post/uniyvmvjopeyyxmphfso forum.dlang.org

- Jonathan M Davis
Jun 04 2017
prev sibling parent reply Mike B Johnson <Mikey Ikes.com> writes:
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:

 [...]


 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




enum X : EnumX
{
    a = 1,
}


struct EnumX
{
	int x;
	alias x this;
	void opAssign(int y)
	{
		x = y;
	}
	double opCall()
	{
             return x;
	}
}

doesn't work because "1" is not castable to EnumX, even though 
EnumX is aliased to an int, and hence it should work fine.

Seems like a bug to me.
Jun 04 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Monday, June 05, 2017 01:30:47 Mike B Johnson via Digitalmars-d-learn 
wrote:

 enum X : EnumX
 {
     a = 1,
 }


 struct EnumX
 {
   int x;
   alias x this;
   void opAssign(int y)
   {
       x = y;
   }
   double opCall()
   {
              return x;
   }
 }

 doesn't work because "1" is not castable to EnumX, even though
 EnumX is aliased to an int, and hence it should work fine.

 Seems like a bug to me.


It's not a bug. The alias this conversion only goes one way. It provides a
way to convert _from_ the type that it's declared on to another type, not
from the other type to the type that it's declared on. There is no way in D
to declare an implicit conversion in the direction you're trying. So, if you
have a struct that wraps an int like this, and you want to assign it an int,
you're going to need to explicitly construct the struct - e.g. EnumX(1).

- Jonathan M Davis
Jun 04 2017
parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote:

 On Monday, June 05, 2017 01:30:47 Mike B Johnson via 
 Digitalmars-d-learn wrote:

 [...]


 It's not a bug. The alias this conversion only goes one way. It 
 provides a way to convert _from_ the type that it's declared on 
 to another type, not from the other type to the type that it's 
 declared on. There is no way in D to declare an implicit 
 conversion in the direction you're trying. So, if you have a 
 struct that wraps an int like this, and you want to assign it 
 an int, you're going to need to explicitly construct the struct 
 - e.g. EnumX(1).

 - Jonathan M Davis


That's pretty crappy! Defeats the whole point!
Jun 04 2017
next sibling parent reply Jonathan M Davis via Digitalmars-d-learn writes:
On Monday, June 05, 2017 02:14:14 Mike B Johnson via Digitalmars-d-learn 
wrote:

 On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote:

 On Monday, June 05, 2017 01:30:47 Mike B Johnson via

 Digitalmars-d-learn wrote:

 [...]


 It's not a bug. The alias this conversion only goes one way. It
 provides a way to convert _from_ the type that it's declared on
 to another type, not from the other type to the type that it's
 declared on. There is no way in D to declare an implicit
 conversion in the direction you're trying. So, if you have a
 struct that wraps an int like this, and you want to assign it
 an int, you're going to need to explicitly construct the struct
 - e.g. EnumX(1).

 - Jonathan M Davis


 That's pretty crappy! Defeats the whole point!


Well, implicit conversions tend to cause a lot of bugs in C++ code, so
Walter decided to restrict them quite a bit more in D than they are in C++.
This therefore prevents a number of bugs in D, but it also prevents implicit
conversions from being used in a number of situations where they're useful.
Whether the end result is better or worse, I don't know and certainly YMMV.
As it is, some of the implicit conversions that we still allow have a
tendency to cause bugs (e.g. conversions between integral values and
character types tend to be error-prone - especially when arrays are involved
- and using implicit conversions with templated code is almost always a bad
idea). So, at times, I tend to think that all implicit conversions should be
banned. But at other times, it would be really nice to be able to have more
than we do (e.g. it would be a lot more user-friendly if you could pass a T
to a function that takes a Nullable!T).

In any case, I think that the reality of the matter with D is that you tend
to have to use explicit conversions rather than implicit ones, and if you're
looking to do much with implicit conversions, you're usually going to be
frustrated, and obviously, that sucks, but at least you're less likely to
have bugs related to implicit conversions.

- Jonathan M Davis
Jun 04 2017
parent Mike B Johnson <Mikey Ikes.com> writes:
On Monday, 5 June 2017 at 03:15:46 UTC, Jonathan M Davis wrote:

 On Monday, June 05, 2017 02:14:14 Mike B Johnson via 
 Digitalmars-d-learn wrote:

 On Monday, 5 June 2017 at 01:42:55 UTC, Jonathan M Davis wrote:

 On Monday, June 05, 2017 01:30:47 Mike B Johnson via

 Digitalmars-d-learn wrote:

 [...]


 It's not a bug. The alias this conversion only goes one way. 
 It provides a way to convert _from_ the type that it's 
 declared on to another type, not from the other type to the 
 type that it's declared on. There is no way in D to declare 
 an implicit conversion in the direction you're trying. So, 
 if you have a struct that wraps an int like this, and you 
 want to assign it an int, you're going to need to explicitly 
 construct the struct - e.g. EnumX(1).

 - Jonathan M Davis


 That's pretty crappy! Defeats the whole point!


 Well, implicit conversions tend to cause a lot of bugs in C++ 
 code, so Walter decided to restrict them quite a bit more in D 
 than they are in C++. This therefore prevents a number of bugs 
 in D, but it also prevents implicit conversions from being used 
 in a number of situations where they're useful. Whether the end 
 result is better or worse, I don't know and certainly YMMV. As 
 it is, some of the implicit conversions that we still allow 
 have a tendency to cause bugs (e.g. conversions between 
 integral values and character types tend to be error-prone - 
 especially when arrays are involved - and using implicit 
 conversions with templated code is almost always a bad idea). 
 So, at times, I tend to think that all implicit conversions 
 should be banned. But at other times, it would be really nice 
 to be able to have more than we do (e.g. it would be a lot more 
 user-friendly if you could pass a T to a function that takes a 
 Nullable!T).

 In any case, I think that the reality of the matter with D is 
 that you tend to have to use explicit conversions rather than 
 implicit ones, and if you're looking to do much with implicit 
 conversions, you're usually going to be frustrated, and 
 obviously, that sucks, but at least you're less likely to have 
 bugs related to implicit conversions.

 - Jonathan M Davis


The problem is bugs are only a possibility. If you remove a 
feature from a language the feature does not exist, period.

So, throwing the baby out with the bath water because he pooped 
in it is not a solution.

Instead, if there is a problem with implicit autonomous 
conversion or construction, then the solution is not to remove 
all implicit conversions or constructions but to remove the 
autonomous part.

e.g., make the user specify the implicit conversion explicitly. 
This way, if bugs do creep in, it is due to the user. It is much 
easier to diagnose and fix then.
Jun 04 2017
prev sibling parent via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
On Sun, Jun 04, 2017 at 08:15:46PM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:

 Well, implicit conversions tend to cause a lot of bugs in C++ code, so
 Walter decided to restrict them quite a bit more in D than they are in C++.


So D has plenty of implicit conversion. It is implicit *construction* that it
lacks.

And alas, C++'s mistake is implicit is default, so it gets used in places it
wasn't intended. We should have just had explicit default with implicit as an
option.
Jun 04 2017