digitalmars.D.learn - enum and const or immutable =?UTF-8?B?4oCYdmFyaWFibGXigJk=?= whose
- Cecil Ward (17/17) Sep 16 2020 A really stupid question, I fear.
- Adam D. Ruppe (6/7) Sep 16 2020 For a non-string array, enum may give runtime allocations that
- Cecil Ward (13/21) Sep 16 2020 So can the result of declaring certain things with enum ever have
- Mike Parker (10/21) Sep 16 2020 No. Think of it as a named literal.
- claptrap (15/22) Sep 17 2020 Seriously how it's implemented is irrelevant. When people use it
- Mike Parker (11/16) Sep 17 2020 I can attest that in the 17 years I've been hanging around here,
- jmh530 (4/15) Sep 17 2020 A talk at dconf 2019 provided an alternative approach to using
- Mike Parker (8/9) Sep 17 2020 And to be clear, my point wasn't about how it's implemented. My
- Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (2/4) Sep 17 2020 C++ made enums stricter by "enum class".
- Simen =?UTF-8?B?S2rDpnLDpXM=?= (24/45) Sep 17 2020 I could imagine some new users may think in
- Mike Parker (18/34) Sep 17 2020 Well, I was already using anonymous enums for compile-time
- Mike Parker (7/8) Sep 17 2020 And, I should add, I have *never* seen C enums as an enumerated
- Steven Schveighoffer (9/11) Sep 17 2020 fun fact: for a (very) brief time, D had a `manifest` keyword that did
- H. S. Teoh (7/20) Sep 17 2020 [...]
- claptrap (19/28) Sep 17 2020 Because they are not the same thing, one is a set of things, one
- Mike Parker (3/7) Sep 17 2020 And in my mind, what is a single-member enum if not a
- claptrap (5/12) Sep 18 2020 Yes all enum members are compile time constants, but not all
- Cecil Ward (4/11) Oct 01 2020 Thank you Mike. That’s exactly what I thought. And it’s another
A really stupid question, I fear. If I have some kind of declaration of some ‘variable’ whose value is strictly known at compile time and I do one of the following (rough syntax) either enum foo = bar; or const foo = bar; or immutable foo = bar; then is there any downside to just using enum all the time? - I don’t need to take the address of foo, in fact want to discourage &foo, (as I said, given that I can do so) Is there any upside either to using enum? I’m a bit nervous about using immutable having had bad allergic reactions when passing immutable ‘variables’ to functions and so just tend to use const or enum.
Sep 16 2020
On Wednesday, 16 September 2020 at 17:12:47 UTC, Cecil Ward wrote:then is there any downside to just using enum all the time?For a non-string array, enum may give runtime allocations that static immutable won't. Generally think of enum as being replaced with the literal representation and array literals actually make a new array. This may or may not matter to you.
Sep 16 2020
On Wednesday, 16 September 2020 at 17:19:13 UTC, Adam D. Ruppe wrote:On Wednesday, 16 September 2020 at 17:12:47 UTC, Cecil Ward wrote: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) <rant>I actually really hate the way enum was bent out of shape and twisted from its original purpose so that finally we end up with a way of defining only one value, not the whole range of permissible values for a type as in the beginning. I wish there were just a keyword ‘constant’ or something (yes, I know, you could just call that something ‘enum’, or ‘const’)</rant>then is there any downside to just using enum all the time?For a non-string array, enum may give runtime allocations that static immutable won't. Generally think of enum as being replaced with the literal representation and array literals actually make a new array. This may or may not matter to you.
Sep 16 2020
On Thursday, 17 September 2020 at 00:32:40 UTC, Cecil WardSo 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. Given enum x = 10, then int num = x is the same as if you had typed int num = 10. Thats’s why you have be careful with array enums if you care about allocations.<rant>I actually really hate the way enum was bent out of shape and twisted from its original purpose so that finally we end up with a way of defining only one value, not the whole range of permissible values for a type as in the beginning. I wish there were just a keyword ‘constant’ or something (yes, I know, you could just call that something ‘enum’, or ‘const’)</rant>enum foo is essentially a shortcut for enum { foo }. It’s neither bent out of shape nor twisted. Consider that C++ added the new keyword constexpr for the same thing. Why pollute the namespace with a new keyword when you already have one that fits?
Sep 16 2020
On Thursday, 17 September 2020 at 01:57:39 UTC, Mike Parker wrote:On Thursday, 17 September 2020 at 00:32:40 UTC, Cecil WardSeriously how it's implemented is irrelevant. When people use it (for that use case) they arn't thinking ohh right here I want an enum with one member. They are thinking I want a constant expression evaluated at compile time. IE, C++ got something right for once, D let the mechanic name the controls on the dashboard. It's an "implementers name" and it's retarded beyond belief. Seriously look up enumeration in a dictionary and explain how that can be twisted to mean "constant expression" or "evaluated at compile time". Names are important, principle of least astonishment and all that, pretty much everyone coming to D is going be WTF in learning about that. And if you keep overloading existing keywords with more and more meanings the code gets harder and harder to grep at first glance.enum foo is essentially a shortcut for enum { foo }. It’s neither bent out of shape nor twisted. Consider that C++ added the new keyword constexpr for the same thing. Why pollute the namespace with a new keyword when you already have one that fits?
Sep 17 2020
On Thursday, 17 September 2020 at 09:44:20 UTC, claptrap wrote:Names are important, principle of least astonishment and all that, pretty much everyone coming to D is going be WTF in learning about that. And if you keep overloading existing keywords with more and more meanings the code gets harder and harder to grep at first glance.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.
Sep 17 2020
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
Sep 17 2020
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?
Sep 17 2020
On Thursday, 17 September 2020 at 10:56:28 UTC, Mike Parker wrote:Are effectively the same thing, whether it's implemented that way or not. So why on earth would a new keyword be necessary?C++ made enums stricter by "enum class".
Sep 17 2020
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:I could imagine some new users may think in enum foo = someTemplate!(); someTemplate could evaluate to a list of values like a 'normal' enum. That's just conjecture, though. The one thing I dislike about enum like this is that we have another keyword that's able to handle manifest constants when tickled correctly, and which doesn't evoke the image of an enumerated list of values: import std.meta : Alias; alias foo = Alias!([1,2,3]); alias bar = Alias!9; alias baz = Alias!someFunc; Some of the above may be doable without Alias!(), but not all. I don't know if you remember the discussions when bracketless enums were introduced back in 2007ish, but alias was the prime contender back then, and is slowly gaining the power that was requested at the time (the ability to alias values as above was added fairly recently). To quote Bill Baxter from way back when (https://forum.dlang.org/post/fjdc4c$2gft$1 digitalmars.com):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?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'. -- SimenWhy does: final int x = 3; make any more intuitive sense than: enum int x = 3; ?There are these things called "words". And they have "meanings"... enum: (short for "enumeration", the noun form of "enumerate") "to specify one after another : list" final: "not to be altered or undone <all sales are final>"
Sep 17 2020
On Thursday, 17 September 2020 at 13:13:46 UTC, Simen Kjærås wrote:To quote Bill Baxter from way back when (https://forum.dlang.org/post/fjdc4c$2gft$1 digitalmars.com):Well, I was already using anonymous enums for compile-time constants anyway. For example, when translating C headers with lots of #defined constants (OpenGL is the poster child), I was doing this in Derelict: enum { GL_THIS = ..., GL_THAT = ..., } So enum for this has always made sense to me. I would have been fine with final, but it would have been a leap for me because of my Java background; I would have kept seeing it as a synonym for const. And I would never have liked the Alias approach. But no matter what solution would have been implemented (final, Alias, new keyword), I would have looked it up then, put my head down and gotten right back to writing code. It just happens the one that's most intuitive to me was picked :-)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'.Why does: final int x = 3; make any more intuitive sense than: enum int x = 3; ?There are these things called "words". And they have "meanings"... enum: (short for "enumeration", the noun form of "enumerate") "to specify one after another : list" final: "not to be altered or undone <all sales are final>"
Sep 17 2020
On Thursday, 17 September 2020 at 13:25:08 UTC, Mike Parker wrote:Well, I was already using anonymous enums for compile-timeAnd, 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.
Sep 17 2020
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
Sep 17 2020
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:[...] 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.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.
Sep 17 2020
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: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.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?
Sep 17 2020
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.
Sep 17 2020
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: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.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.
Sep 18 2020
On Thursday, 17 September 2020 at 01:57:39 UTC, Mike Parker wrote:On Thursday, 17 September 2020 at 00:32:40 UTC, Cecil WardThank 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.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.
Oct 01 2020