On 26.01.2012 14:59, Trass3r wrote:
> I thought it'd be good to outsource this question from the other thread
> about enums as flags.
>
> Is there any merit in having implicit conversion to the basetype?

Allowing it to be used as an argument when calling C functions?

Without it, how would you support eg the Windows API?

>> Is there any merit in having implicit conversion to the basetype?
>
> Allowing it to be used as an argument when calling C functions?

extern(C):
enum Bla : int {...}
void foo(Bla b);

How does this require implicit conversion?
The codegen treats Bla like basetype anyway.

Trass3r wrote:

> It's ill-defined. There are 4 possible types of typedef: http://d.puremagic.com/issues/show_bug.cgi?id=5467
[...]
> Again, this thread is all about discussing the right way to do it and not  about what the buggy and holey spec reads.
[...]
> I don't see any merit in that.

You meight be blind. The only way to eject this possibility is to prove that there cannot be any merit.

Currently a good approximation of your intentions for the replacment of `enum's seems to be a wood of rooted almost-DAGs on types, where the edges in the DAGs represent the allowed implicit conversions, the inner nodes are represented by tags and the leaves are represented by members. Maybe that the "almost" is not necessary.

-manfred

El 26/01/2012 14:59, Trass3r escribió:
> I thought it'd be good to outsource this question from the other thread
> about enums as flags.
>
> Is there any merit in having implicit conversion to the basetype?
> Imo it only introduces a severe bug source and brings no advantages.

> A better example is something like
> if (b && Bla.S2) // written '&&' instead of '&' by mistake, will
> silently pass
> Heck even +,-,... work.

I kind of agree. I understand enums as a way to define "tags" or flags used to define things like file open mode Read, Write, ReadWrite, endianness BigEndian, LittleEndian, socket type Stream/Packet, etc. things that under the hood are represented by integer numbers but that don't represent *quantities*, so should not work the same way as integers. What is the result of subtracting or multiplying LittleEndian and BigEndian? Does not make sense. Bitwise operations would be OK because logica tags can be combined, but little more.

And this brings the question of whether implicit casting from int to bool is a good thing (or making any integer a valid boolean value). The same way, true and false are not quantities and can't be used in arithmetic. Even if they are internally represented as 1 and 0, they should not be the same thing as numbers. IMO, Java did it better in making them distinct. With a non-int-convertible bool your above weird example would not work.

Alvaro wrote:

>  With a non-int-convertible bool your above weird
> example would not work.

But that the example works is not the fault of the existence of enums. It is due to the fact that omission, inclusion or change of one character can produce a different value without any warning.

-manfred

On Thu, 26 Jan 2012 23:49:40 +0100, Alvaro <alvaroDotSegura@gmail.com>
wrote:

> El 26/01/2012 14:59, Trass3r escribió:
>> I thought it'd be good to outsource this question from the other thread
>> about enums as flags.
>>
>> Is there any merit in having implicit conversion to the basetype?
>> Imo it only introduces a severe bug source and brings no advantages.
>
>> A better example is something like
>> if (b && Bla.S2) // written '&&' instead of '&' by mistake, will
>> silently pass
>> Heck even +,-,... work.
>
> I kind of agree. I understand enums as a way to define "tags" or flags used to define things like file open mode Read, Write, ReadWrite, endianness BigEndian, LittleEndian, socket type Stream/Packet, etc. things that under the hood are represented by integer numbers but that don't represent *quantities*, so should not work the same way as integers. What is the result of subtracting or multiplying LittleEndian and BigEndian? Does not make sense. Bitwise operations would be OK because logica tags can be combined, but little more.

Sometimes, bitwise operations make sense, other times not. Enums play two
roles in D - that of an enumeration and that of a set of flags. Only for
the latter do bitwise operations make sense.

On 01/26/2012 08:17 PM, Simen Kjærås wrote:
> On Thu, 26 Jan 2012 23:49:40 +0100, Alvaro <alvaroDotSegura@gmail.com>
> wrote:
>
>> El 26/01/2012 14:59, Trass3r escribió:
>>> I thought it'd be good to outsource this question from the other thread
>>> about enums as flags.
>>>
>>> Is there any merit in having implicit conversion to the basetype?
>>> Imo it only introduces a severe bug source and brings no advantages.
>>
>>> A better example is something like
>>> if (b && Bla.S2) // written '&&' instead of '&' by mistake, will
>>> silently pass
>>> Heck even +,-,... work.
>>
>> I kind of agree. I understand enums as a way to define "tags" or flags
>> used to define things like file open mode Read, Write, ReadWrite,
>> endianness BigEndian, LittleEndian, socket type Stream/Packet, etc.
>> things that under the hood are represented by integer numbers but that
>> don't represent *quantities*, so should not work the same way as
>> integers. What is the result of subtracting or multiplying
>> LittleEndian and BigEndian? Does not make sense. Bitwise operations
>> would be OK because logica tags can be combined, but little more.
>
> Sometimes, bitwise operations make sense, other times not. Enums play two
> roles in D - that of an enumeration and that of a set of flags. Only for
> the latter do bitwise operations make sense.

You'd think that with some use of a templated struct and some "alias this" we'd be able to have a strongly-typed type for storing sets of flags.  It could even offer convenience functions like "getFlag" and "setFlag" to make the code read a bit nicer.

On 26/01/12 21:26, Trass3r wrote:
>>> Is there any merit in having implicit conversion to the basetype?
>>
>> Allowing it to be used as an argument when calling C functions?
>
> extern(C):
> enum Bla : int {...}
> void foo(Bla b);
>
> How does this require implicit conversion?
> The codegen treats Bla like basetype anyway.

Some of the Windows functions are made of multiple enums of different types, ORed together.

>> extern(C):
>> enum Bla : int {...}
>> void foo(Bla b);
>>
>> How does this require implicit conversion?
>> The codegen treats Bla like basetype anyway.
>
> Some of the Windows functions are made of multiple enums of different types, ORed together.

-.- Microsuckx.
Then I think it should either become a combined enum or just anonymous ones (+ aliases to basetype perhaps).

On Fri, 27 Jan 2012 13:34:06 +0100, Chad J <chadjoan@__spam.is.bad__gmail.com> wrote:

> On 01/26/2012 08:17 PM, Simen Kjærås wrote:
>> On Thu, 26 Jan 2012 23:49:40 +0100, Alvaro <alvaroDotSegura@gmail.com> wrote:
>>
>>> El 26/01/2012 14:59, Trass3r escribió:
>>>> I thought it'd be good to outsource this question from the other
>>>> thread
>>>> about enums as flags.
>>>>
>>>> Is there any merit in having implicit conversion to the basetype? Imo it only introduces a severe bug source and brings no advantages.
>>>
>>>> A better example is something like
>>>> if (b && Bla.S2) // written '&&' instead of '&' by mistake, will
>>>> silently pass
>>>> Heck even +,-,... work.
>>>
>>> I kind of agree. I understand enums as a way to define "tags" or flags used to define things like file open mode Read, Write, ReadWrite, endianness BigEndian, LittleEndian, socket type Stream/Packet, etc. things that under the hood are represented by integer numbers but that don't represent *quantities*, so should not work the same way as integers. What is the result of subtracting or multiplying LittleEndian and BigEndian? Does not make sense. Bitwise operations would be OK because logica tags can be combined, but little more.
>>
>> Sometimes, bitwise operations make sense, other times not. Enums play
>> two
>> roles in D - that of an enumeration and that of a set of flags. Only for
>> the latter do bitwise operations make sense.
>
> You'd think that with some use of a templated struct and some "alias this" we'd be able to have a strongly-typed type for storing sets of flags.  It could even offer convenience functions like "getFlag" and "setFlag" to make the code read a bit nicer.

Like that attached?