www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Explicit casting of enum -- intentional restriction?

reply rcorre <ryan rcorre.net> writes:
I just tried to compile an old project and the following failed:

---
enum Paths : string {
   bitmapDir     = "content/image",
   fontDir       = "content/font",
   soundDir      = "content/sound",
...

if (Paths.preferences.exists)
     ...
---

It turns out members of Paths are no longer implicitly converted 
to string, and I needed to use

if ((cast(string)Paths.preferences).exists)

Is this an intentional limitation or a regression? I didn't see 
it in the last few changelogs but I'll admit I didn't check them 
rigorously.
Oct 01 2016
next sibling parent Namespace <rswhite4 gmail.com> writes:
The Code below still works, so I guess it's some problem with the 
constraint of "exists".

----
import std.stdio;

enum Foo
{
	A = "B"
}

void test(string a)
{
}

void main()
{
	test(Foo.A);
	Foo.A.test();
}
----
Oct 01 2016
prev sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Saturday, 1 October 2016 at 20:52:48 UTC, rcorre wrote:

 I just tried to compile an old project and the following failed:

 ---
 enum Paths : string {
   bitmapDir     = "content/image",
   fontDir       = "content/font",
   soundDir      = "content/sound",
 ...

 if (Paths.preferences.exists)
     ...
 ---

 It turns out members of Paths are no longer implicitly 
 converted to string, and I needed to use

 if ((cast(string)Paths.preferences).exists)

 Is this an intentional limitation or a regression? I didn't see 
 it in the last few changelogs but I'll admit I didn't check 
 them rigorously.


This is the PR that broke it:
https://github.com/dlang/phobos/pull/3447
Oct 02 2016
parent reply rcorre <ryan rcorre.net> writes:
On Sunday, 2 October 2016 at 10:52:59 UTC, Marc Schütz wrote:

 On Saturday, 1 October 2016 at 20:52:48 UTC, rcorre wrote:

 I just tried to compile an old project and the following 
 failed:

 ---
 enum Paths : string {
   bitmapDir     = "content/image",
   fontDir       = "content/font",
   soundDir      = "content/sound",
 ...

 if (Paths.preferences.exists)
     ...
 ---

 It turns out members of Paths are no longer implicitly 
 converted to string, and I needed to use

 if ((cast(string)Paths.preferences).exists)

 Is this an intentional limitation or a regression? I didn't 
 see it in the last few changelogs but I'll admit I didn't 
 check them rigorously.


 This is the PR that broke it:
 https://github.com/dlang/phobos/pull/3447


Thanks for tracking that down. I think the bug is that a 
string-typed enum passes isSomeString but not isInputRange. It 
should either be both or neither. I filed 
https://issues.dlang.org/show_bug.cgi?id=16573.
Oct 02 2016
parent Jonathan M Davis via Digitalmars-d-learn writes:
On Sunday, October 02, 2016 12:00:05 rcorre via Digitalmars-d-learn wrote:

 Thanks for tracking that down. I think the bug is that a
 string-typed enum passes isSomeString but not isInputRange. It
 should either be both or neither. I filed
 https://issues.dlang.org/show_bug.cgi?id=16573.


I really don't think that it makes sense for isSomeString to be true for an
enum (I thought that we'd made it so that it wasn't, so the fact that it
currently is is quite surprising and definitely annoying). Making
isConvertibleToString true for enums (since for some reason, it's not) would
make exists work with enums again, but having both isSomeString and
isConvertibleToString be true for enums could be a problem.

I really think that making isSomeString false for enums with a base type of
string is what we would ideally do (that and make isConvertibleToString true
for those enums), but I'm not sure that we could get away with it at this
point, since there may be a fair bit of code in the wild depending on
isSomeString being true for enums with a base type of string. But the
situation with isInputString helps make it clear why treating an enum with a
base type of string as if it were a string rather than just convertible to
string is a problem.

- Jonathan M Davis
Oct 02 2016