On Tue, Apr 08, 2014 at 09:46:51PM +0000, Meta wrote:
> On Tuesday, 8 April 2014 at 19:09:55 UTC, Andrei Alexandrescu wrote:
[...]
> >3. What is the priority of improving enums in the larger picture of other things we must do?
> 
> Enums could stand to be improved, but finishing the implementation of the language should take precedent.

Yes! There are much bigger fish to fry than enums right now. Let's not lose sight of the forest for the trees.


> Figuring out scope (which Adam Ruppe had some good ideas for)

Yes! I've been waiting for scope for a looong time...


> and shared is what instantly comes to mind... These are probably also the two hardest tasks remaining.

I haven't done concurrent programming in D yet... But from what I hear, shared still needs a bit of work before it's presentable.


> Then there's also making objects default non-null, tuple syntax, qualified constructors...

I dunno, default non-null objects is pretty low in my priority list, and tuple syntax is just icing on the cake. I think there are other things that are more important. (*ahem*cough*AA's*ahem* -- though admittedly that's more an implementation issue, not a language issue).

Qualified ctors, maybe. Haven't run into those issues myself, though, so I can't really say.


T

-- 
Question authority. Don't ask why, just do it.

On 4/8/14, 2:46 PM, Meta wrote:
> You could consider it an embarrassment that we should need a library
> solution to cover up for (arguably) bad design in the language.

I'm thinking complementing, not covering up. -- Andrei

On 4/8/14, 2:49 PM, Steven Schveighoffer wrote:
> On Tue, 08 Apr 2014 17:12:17 -0400, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> 6. An integral type, some of which have names:
>>
>> enum Color {
>>      Red = 0xFF0000,
>>      Green = 0x00FF00,
>>      Blue = 0x0000FF00,
>>      Fred = 0x123456,
>>      White = 0xFFFFFF }
>
> That was Andrei's UserId example...

I'd say it's different because one would want operations on colors that don't make sense on UserId.

Andrei

On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
> 1. Is the current design damaging enough (= allows enough wrong/buggy code to pass through) to warrant a breaking tightening?

What I would very much like to see happen is that any time that any operation is done on a variable of an enum type and that operation is not _guaranteed_ to result in a valid enum value, the result should be the enum's base type and and not the enum type - e.g. or-ing enum flags together isn't going to result in a valid enum and shouldn't be typed as such, but unfortunately, it currently _is_ typed as such.

And I expect that the vast majority of cases where such a change would break code would catch bugs.

- Jonathan M Davis

On Wednesday, 9 April 2014 at 11:39:37 UTC, Jonathan M Davis wrote:
> On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
>> 1. Is the current design damaging enough (= allows enough wrong/buggy
>> code to pass through) to warrant a breaking tightening?
>
> What I would very much like to see happen is that any time that any operation
> is done on a variable of an enum type and that operation is not _guaranteed_
> to result in a valid enum value, the result should be the enum's base type and
> and not the enum type - e.g. or-ing enum flags together isn't going to result
> in a valid enum and shouldn't be typed as such, but unfortunately, it
> currently _is_ typed as such.
>
> And I expect that the vast majority of cases where such a change would break
> code would catch bugs.
>
> - Jonathan M Davis

I think this is a good idea. That way I think you'd only be able to get undefined enum values by casting.

On Wednesday, April 09, 2014 12:18:23 w0rp wrote:
> On Wednesday, 9 April 2014 at 11:39:37 UTC, Jonathan M Davis
> 
> wrote:
> > On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
> >> 1. Is the current design damaging enough (= allows enough
> >> wrong/buggy
> >> code to pass through) to warrant a breaking tightening?
> > 
> > What I would very much like to see happen is that any time that
> > any operation
> > is done on a variable of an enum type and that operation is not
> > _guaranteed_
> > to result in a valid enum value, the result should be the
> > enum's base type and
> > and not the enum type - e.g. or-ing enum flags together isn't
> > going to result
> > in a valid enum and shouldn't be typed as such, but
> > unfortunately, it
> > currently _is_ typed as such.
> > 
> > And I expect that the vast majority of cases where such a
> > change would break
> > code would catch bugs.
> > 
> > - Jonathan M Davis
> 
> I think this is a good idea. That way I think you'd only be able to get undefined enum values by casting.

Exactly.

- Jonathan M Davis

On Wednesday, 9 April 2014 at 11:39:37 UTC, Jonathan M Davis wrote:
> On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
>> 1. Is the current design damaging enough (= allows enough wrong/buggy
>> code to pass through) to warrant a breaking tightening?
>
> What I would very much like to see happen is that any time that any operation
> is done on a variable of an enum type and that operation is not _guaranteed_
> to result in a valid enum value, the result should be the enum's base type and
> and not the enum type - e.g. or-ing enum flags together isn't going to result
> in a valid enum and shouldn't be typed as such, but unfortunately, it
> currently _is_ typed as such.
>
> And I expect that the vast majority of cases where such a change would break
> code would catch bugs.
>
> - Jonathan M Davis

+1

On 4/9/14, 5:18 AM, w0rp wrote:
> On Wednesday, 9 April 2014 at 11:39:37 UTC, Jonathan M Davis wrote:
>> On Tuesday, April 08, 2014 12:08:46 Andrei Alexandrescu wrote:
>>> 1. Is the current design damaging enough (= allows enough wrong/buggy
>>> code to pass through) to warrant a breaking tightening?
>>
>> What I would very much like to see happen is that any time that any
>> operation
>> is done on a variable of an enum type and that operation is not
>> _guaranteed_
>> to result in a valid enum value, the result should be the enum's base
>> type and
>> and not the enum type - e.g. or-ing enum flags together isn't going to
>> result
>> in a valid enum and shouldn't be typed as such, but unfortunately, it
>> currently _is_ typed as such.
>>
>> And I expect that the vast majority of cases where such a change would
>> break
>> code would catch bugs.
>>
>> - Jonathan M Davis
>
> I think this is a good idea. That way I think you'd only be able to get
> undefined enum values by casting.

Too restrictive. What is a valid enum value? Would an enum flags need to ascribe a name to every possible combination?

One possibility would be to guarantee all operations are between TheEnum.min and TheEnum.max. Users who need operations would need to define those limits.


Andrei

Am 08.04.2014 21:08, schrieb Andrei Alexandrescu:
> (moving http://goo.gl/ZISWwN to this group)
>
> On 4/7/14, 3:41 PM, w0rp wrote:
>> Yeah, I've seen this happen before. I think we could actually introduce
>> a little more type safety on enums without a great deal of breakage. It
>> would be nice to have a final switch give you as much of a guarantee
>> about what it's doing as it can.
>
> People use enums for things such as:
>
> 1. A discrete set of categorical values:
>
> enum State { initial, waiting, running, done }
>
> That's probably the most common use, and the one that prompted the
> moniker "enum(eration)".
>

This seems to be exactly the use case for which C++ enum class has been designed. But there is one major flaw in C++ enum class. Usually if you have a discrete set you want to use it to index into an array.

E.g.

enum ShaderType { Vertex, Geometry, Pixel };
Shader[ShaderType.max] shaders;
shaders[ShaderType.Vertex] = new Shader();

In C++ you can't index arrays using a enum class without casting them first. This is in my opinion a major problem. We should not make the same mistake, in case we redesign enums.

Kind Regards
Benjamin Thaut

On 4/9/14, 8:44 AM, Benjamin Thaut wrote:
> Am 08.04.2014 21:08, schrieb Andrei Alexandrescu:
>> (moving http://goo.gl/ZISWwN to this group)
>>
>> On 4/7/14, 3:41 PM, w0rp wrote:
>>> Yeah, I've seen this happen before. I think we could actually introduce
>>> a little more type safety on enums without a great deal of breakage. It
>>> would be nice to have a final switch give you as much of a guarantee
>>> about what it's doing as it can.
>>
>> People use enums for things such as:
>>
>> 1. A discrete set of categorical values:
>>
>> enum State { initial, waiting, running, done }
>>
>> That's probably the most common use, and the one that prompted the
>> moniker "enum(eration)".
>>
>
> This seems to be exactly the use case for which C++ enum class has been
> designed. But there is one major flaw in C++ enum class. Usually if you
> have a discrete set you want to use it to index into an array.
>
> E.g.
>
> enum ShaderType { Vertex, Geometry, Pixel };
> Shader[ShaderType.max] shaders;
> shaders[ShaderType.Vertex] = new Shader();
>
> In C++ you can't index arrays using a enum class without casting them
> first. This is in my opinion a major problem. We should not make the
> same mistake, in case we redesign enums.

Very true. In hhvm, we tried an enum class to avoid bugs with using wrong indices in a couple of specific arrays. There were so many darned casts around, we had to revert the change.

Andrei