View mode: basic / threaded / horizontal-split · Log in · Help
January 26, 2012
Re: strong enums: why implicit conversion to basetype?
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?
January 26, 2012
Re: strong enums: why implicit conversion to basetype?
>> 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.
January 26, 2012
Re: strong enums: why implicit conversion to basetype?
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
January 26, 2012
Re: strong enums: why implicit conversion to basetype?
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.
January 26, 2012
Re: strong enums: why implicit conversion to basetype?
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
January 27, 2012
Re: strong enums: why implicit conversion to basetype?
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.
January 27, 2012
Re: strong enums: why implicit conversion to basetype?
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.
January 27, 2012
Re: strong enums: why implicit conversion to basetype?
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.
January 27, 2012
Re: strong enums: why implicit conversion to basetype?
>> 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).
January 27, 2012
Re: strong enums: why implicit conversion to basetype?
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?
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home