Re: Explicit casting of enum -- intentional restriction?

[Jonathan M Davis via Digitalmars-d-learn]

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

Re: Explicit casting of enum -- intentional restriction?

[rcorre via Digitalmars-d-learn]

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.

Re: Explicit casting of enum -- intentional restriction?

[Marc Schütz via Digitalmars-d-learn]

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

Re: Explicit casting of enum -- intentional restriction?

[Namespace via Digitalmars-d-learn]

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

Explicit casting of enum -- intentional restriction?

[rcorre via Digitalmars-d-learn]

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.