On Thursday, 17 September 2020 at 13:25:08 UTC, Mike Parker wrote:
>
> Well, I was already using anonymous enums for compile-time

And, I should add, I have *never* seen C enums as an enumerated list of values. I've always seen them as an alternative for #defined constants because they're anonymous. It's *named* enums that I view as enumerated lists of values. So, in terms of vocabulary definitions, that was already a non-issue for me before I even discovered D.

On 9/17/20 9:13 AM, Simen Kjærås wrote:

> To be clear: I don't mind 'enum' being used this way, but if I were to do things over again, I would have used 'alias'.

fun fact: for a (very) brief time, D had a `manifest` keyword that did exactly what enum does in this instance (not even sure it made it into a release).

enum is a head scratcher of a name, for sure. But it works out just fine once you get used to it. I think of it as "compile time". To be honest, for what it does, enum is a very poor name. But because it's consistent, it works.

-Steve

On Thu, Sep 17, 2020 at 06:06:56PM -0400, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 9/17/20 9:13 AM, Simen Kjærås wrote:
> 
> > To be clear: I don't mind 'enum' being used this way, but if I were to do things over again, I would have used 'alias'.
> 
> fun fact: for a (very) brief time, D had a `manifest` keyword that did
> exactly what enum does in this instance (not even sure it made it into
> a release).
> 
> enum is a head scratcher of a name, for sure. But it works out just fine once you get used to it. I think of it as "compile time". To be honest, for what it does, enum is a very poor name. But because it's consistent, it works.
[...]

In my mind, I just substitute 'enum' with 'manifest constant' and everything makes sense. ;-)


T

-- 
What are you when you run out of Monet? Baroque.

On Thursday, 17 September 2020 at 10:56:28 UTC, Mike Parker wrote:
> On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote:
>
>> Seriously how it's implemented is irrelevant.
>
> And to be clear, my point wasn't about how it's implemented. My point was that:
>
> enum { foo = 10; }
>
> and
>
> enum foo = 10;
>
> Are effectively the same thing, whether it's implemented that way or not. So why on earth would a new keyword be necessary?

Because they are not the same thing, one is a set of things, one is a single thing. That you say they are "effectively the same" is what Im getting at, just because they can be implemented the same, or one feature can be repurposed to serve the other need, doesnt mean they should. It's like...

int x;
int[1] x;

They are effectively the same thing, a single int on the stack if declared locally, but they are conceptually different. And to me programming is not just about getting the job done but about being able to express the concept / design precisely.

For example, this to me is utter nonsense...

enum auto isTwoWayCompatible(alias fn, T1, T2);

It makes about as much sense as using "enum" in place of "struct".

If enum means manifiest constant, or compile time constant, then it makes more sense, as you allude to in a later post. But 'enum' is a terrible name for that and I dont think my brain will ever stop finding it incongruous.

On Thursday, 17 September 2020 at 10:53:48 UTC, Mike Parker wrote:
> [snip]
>
> I can attest that in the 17 years I've been hanging around here, the fact that enum is used to indicate a manifest constant has not been a serious source of WTF posts. So I think "pretty much everyone coming to D" have decided it's either perfectly fine or perfectly tolerable. It's the sort of thing that may not be obvious, but once you figure you absorb it and get down to coding. I know some people would prefer it were something else and some don't care. I'm squarely in the camp that thinks it makes perfect sense and it would be silly to create a new keyword for it.

A talk at dconf 2019 provided an alternative approach to using enum for manifest constants:

http://dconf.org/2019/talks/marques.html

On Thursday, 17 September 2020 at 22:25:47 UTC, claptrap wrote:

> If enum means manifiest constant, or compile time constant, then it makes more sense, as you allude to in a later post. But 'enum' is a terrible name for that and I dont think my brain will ever stop finding it incongruous.

And in my mind, what is a single-member enum if not a compile-time constant? This is why naming is hard.

On Friday, 18 September 2020 at 02:49:30 UTC, Mike Parker wrote:
> On Thursday, 17 September 2020 at 22:25:47 UTC, claptrap wrote:
>
>> If enum means manifiest constant, or compile time constant, then it makes more sense, as you allude to in a later post. But 'enum' is a terrible name for that and I dont think my brain will ever stop finding it incongruous.
>
> And in my mind, what is a single-member enum if not a compile-time constant? This is why naming is hard.

Yes all enum members are compile time constants, but not all compile time constants are enum members. The later is a subset of the former, but the reverse is not true. So the name implies the subset but the feature implements the superset.

On Thursday, 17 September 2020 at 01:57:39 UTC, Mike Parker wrote:
> On Thursday, 17 September 2020 at 00:32:40 UTC, Cecil Ward
>>
>> So can the result of declaring certain things with enum ever have an _address_ then? (According to legit D code that is, never mind the underlying implementation details, which may not be observable)
>
> No. Think of it as a named literal.
>
Thank you Mike. That’s exactly what I thought. And it’s another reason in favour of using enum - that it forbids address-taking and so declares that there will be none.