http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #40 from Manu <turkeyman@gmail.com> 2012-11-27 07:59:18 PST ---
(In reply to comment #38)
> That won't work for methods, but that might not be the use case.

Yeah, if it were in std.traits, I would expect it to work on methods too.


(In reply to comment #37)
> (In reply to comment #31)
> > I am seeing a few error cases:
> > 
> > enum j { k = 10 }
> > 
> > pragma(msg, isFunction!(j.k));
> > pragma(msg, isManifestConstant!(j.k));
> > pragma(msg, isPropertyFunction!(j.k));
> > pragma(msg, isVariable!(j.k));
> > 
> > These all throw errors.
> 
> Fixed.

Huzzah!

> This is a compiler bug, not an issue of isFunction template. I filed new bug 9083.

Amazing!
You sir are awesome! :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #41 from Manu <turkeyman@gmail.com> 2012-11-27 09:26:36 PST ---
(In reply to comment #37)
> This is a compiler bug, not an issue of isFunction template. I filed new bug 9083.

I found another one, probably a compiler bug too, but I'll paste it here since it depends on your new isVariable trait:

Boiled down as much as I could...

class Test
{
    void func()
    {
        void templateFunc( T )( ref const T obj )
        {
            foreach( m; __traits( allMembers, T ) )
            {
                pragma(msg, m);
                static if( isVariable!( __traits(getMember, T, m) ) )
                {
                    //...
                }
            }
        }

        templateFunc( this );
    }

    // some class members
    int x;
}

isVariable throws lots of errors when considering the class members.

Note:
  __traits(allMembers, T) and __traits(getMember, T, m)

These should also work with class instances, not just types, eg:
  __traits(allMembers, obj) and __traits(getMember, obj, m)

And these combinations should also work:
  __traits(allMembers, T) and __traits(getMember, obj, m)
  __traits(allMembers, obj) and __traits(getMember, T, m)

All these configurations throw errors, and the errors are different for each configuration.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065


Rob T <alanb@ucora.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alanb@ucora.com


--- Comment #42 from Rob T <alanb@ucora.com> 2012-11-27 22:39:06 PST ---
(In reply to comment #26)
> (In reply to comment #24)
> > What the compiler calls stuff internally has no bearing on what users of the language will call things.
> 
> It's not an internal thing, that declaration is not an enum declaration, period. enum is used as a keyword for more than one thing, which is bad, but it's too late to change it now.
> 
> We shouldn't name things in Phobos based on what people might think is right or looks right, but based on what the things really are.
> 
> It's a shame we don't have a 'manifest' keyword of some sort, it would help avoid confusion. I guess 'enum' was used to cut back on having too many keywords in the language.
> 
> Anyway it's documented behavior, see "manifest constants" here (it's at the bottom): http://dlang.org/enum.html

As far as I was concerned, these are anonymous enum members in the case where there's only one member and the { } were omitted. I understood it in this way by reading the specification here: http://dlang.org/enum.html. It actual made some sense to me.

The use of "manifest constant" terminology elsewhere will likely cause a lot of confusion. Why not term it as an "anonymous enum constant", or "enum manifest constant" if that suits the usage better. Term it anything so long as "enum" is in there so as to avoid the inevitable confusion elsewhere.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #43 from Don <clugdbug@yahoo.com.au> 2012-11-28 00:36:26 PST ---
(In reply to comment #42)
> (In reply to comment #26)
> > (In reply to comment #24)
> > > What the compiler calls stuff internally has no bearing on what users of the language will call things.
> > 
> > It's not an internal thing, that declaration is not an enum declaration, period. enum is used as a keyword for more than one thing, which is bad, but it's too late to change it now.
> > 
> > We shouldn't name things in Phobos based on what people might think is right or looks right, but based on what the things really are.
> > 
> > It's a shame we don't have a 'manifest' keyword of some sort, it would help avoid confusion. I guess 'enum' was used to cut back on having too many keywords in the language.
> > 
> > Anyway it's documented behavior, see "manifest constants" here (it's at the bottom): http://dlang.org/enum.html
> 
> As far as I was concerned, these are anonymous enum members in the case where there's only one member and the { } were omitted. I understood it in this way by reading the specification here: http://dlang.org/enum.html. It actual made some sense to me.
> 
> The use of "manifest constant" terminology elsewhere will likely cause a lot of confusion. Why not term it as an "anonymous enum constant", or "enum manifest constant" if that suits the usage better. Term it anything so long as "enum" is in there so as to avoid the inevitable confusion elsewhere.

The history of this was:

In D1, const XXX = YYY; declared a manifest constant. You couldn't take the address of it. With the change to const in D2, this no longer worked. I argued that we needed a way of doing manifest constants. Walter started implementing it as 'manifest'. Andrei argued for it to reuse 'enum' to reduce the number of keywords. Almost everybody was angry about overloading 'enum' and there was a huge fight, but Andrei won in the end. Yes it causes confusion.

They are not enums, there is nothing enumerated about them. It's just an overloaded keyword.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #44 from Manu <turkeyman@gmail.com> 2012-11-28 01:27:11 PST ---
(In reply to comment #43)
> The history of this was:
> 
> In D1, const XXX = YYY; declared a manifest constant. You couldn't take the address of it. With the change to const in D2, this no longer worked. I argued that we needed a way of doing manifest constants. Walter started implementing it as 'manifest'. Andrei argued for it to reuse 'enum' to reduce the number of keywords. Almost everybody was angry about overloading 'enum' and there was a huge fight, but Andrei won in the end. Yes it causes confusion.
> 
> They are not enums, there is nothing enumerated about them. It's just an overloaded keyword.

Andrei was absolutely correct, as far as any user is concerned:

enum E { K = 10 } // named enum
enum   { K = 10 } // anonymous enum
enum     K = 10;  // obvious sugar to save bracket spam

As said previously, I give exactly zero shits how it's implemented internally,
or the history of it.
The way it's documented now and the syntax chosen makes perfect sense, and any
attempt to make K be somehow distinct in any of these cases is a mistake which
will only lead to confusion.

If E is an enum type, then K is an enum value, or an enum constant... (i like enum value better; 'constant' is verbose is implicit)

Why would any normal user reasonably expect the term 'manifest' (which I still have no idea what it means) to appear in this context?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #45 from Rob T <alanb@ucora.com> 2012-11-28 01:43:28 PST ---
(In reply to comment #43)
> The history of this was:
> 
> In D1, const XXX = YYY; declared a manifest constant. You couldn't take the address of it. With the change to const in D2, this no longer worked. I argued that we needed a way of doing manifest constants. Walter started implementing it as 'manifest'. Andrei argued for it to reuse 'enum' to reduce the number of keywords. Almost everybody was angry about overloading 'enum' and there was a huge fight, but Andrei won in the end. Yes it causes confusion.
> 
> They are not enums, there is nothing enumerated about them. It's just an overloaded keyword.

Interesting history, but the thing is that from a D users POV, it is a member of an anonymous enum, and that does not change however it may be internally represented, or historically thought of.

I look at it this way

enum { a = 2 } // anonymous enum set to 2 with one member
enum a = 2; // anonymous enum set to 2 with one member and optional {} removed
enum a; // anonymous enum unset with one member and optional {} removed

How is this not what the specification says it is? How it may be internally represented is invisible to the user, what the user sees is only what is seen in terms of how the language represents the concept. This is an enum, and if it is not, then that only matters if it does not behave like all the other enum members, otherwise it may as well be viewed as if it is an enum member. I suspect this was Andrei's argument, because it actually does fit nicely into place.

If I'm going to get mentally confabulated again because it does not work as I would expect an enum to work, then I'll be up in arms about it for sure, so I'm interested in knowing exactly how it is not like an enum, not internally, not historically, but in terms of usage from a programmers POV?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #46 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-11-28 03:06:54 PST ---
(In reply to comment #45)
> interested in knowing exactly how it is not like an enum, not internally, not historically, but in terms of usage from a programmers POV?

It doesn't enumerate anything? Enumerations are collections of items, aren't they? How is one element a collection?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #47 from Manu <turkeyman@gmail.com> 2012-11-28 04:05:14 PST ---
(In reply to comment #46)
> (In reply to comment #45)
> > interested in knowing exactly how it is not like an enum, not internally, not historically, but in terms of usage from a programmers POV?
> 
> It doesn't enumerate anything? Enumerations are collections of items, aren't they? How is one element a collection?

Then you need to disallow assigning explicit values to enum keys, that's not
strictly an enumeration either.
It just so happens that anonymous enums containing only a single value have a
nice little sugar such that you don't need to write the brackets. This is
because, in practise, this turns out to be a surprisingly common usage case so
the little sugar is nice.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #48 from Don <clugdbug@yahoo.com.au> 2012-11-28 06:39:16 PST ---
(In reply to comment #47)
> (In reply to comment #46)
> > (In reply to comment #45)
> > > interested in knowing exactly how it is not like an enum, not internally, not historically, but in terms of usage from a programmers POV?
> > 
> > It doesn't enumerate anything? Enumerations are collections of items, aren't they? How is one element a collection?
> 
> Then you need to disallow assigning explicit values to enum keys, that's not
> strictly an enumeration either.
> It just so happens that anonymous enums containing only a single value have a
> nice little sugar such that you don't need to write the brackets. This is
> because, in practise, this turns out to be a surprisingly common usage case so
> the little sugar is nice.

I believe the similarity you've listed is false. An enumerated type must be integral (it must be countable!) A manifest constant, however, can be anything - a struct literal, for example.

I think what has happened is that C had a very sloppy enum design, where it mixed integral manifest constants with enumerated types. Instead of tightening up 'enum', we used the existing sloppiness as an excuse to make it worse.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9065



--- Comment #49 from Manu <turkeyman@gmail.com> 2012-11-28 06:59:34 PST ---
(In reply to comment #48)
> I believe the similarity you've listed is false. An enumerated type must be integral (it must be countable!) A manifest constant, however, can be anything - a struct literal, for example.

... really? But D supports typing enums:

enum E : string
{
  X = "hello",
  Y = "world"
}

I tried:

enum E : string
{
  X = "hello",
  Y
}

Sure, this would normally try and increment by one, but since it's not integral
I got this error: incompatible types for (("hello") + (1)): 'S' and 'int'

Makes perfect sense to me, apparently you just lose the auto-increment behaviour if the enums are not an integeral type? (although the error message could be clearer)

So perhaps you mean, "must be integral if you want auto-increment behaviour"? Often enough you don't even want auto-increment, you want a collection of meaningful pre-defined values, I think that's just as good a definition of the term 'enumeration', auto-increment is not fundamental to this enumerated type concept in my mind. In fact, I think I might even use all-explicit values more often than auto-incremented ones in my code.


> I think what has happened is that C had a very sloppy enum design, where it mixed integral manifest constants with enumerated types. Instead of tightening up 'enum', we used the existing sloppiness as an excuse to make it worse.

Worse? It's perfect... >_<

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------