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



--- Comment #20 from Kenji Hara <k.hara.pg@gmail.com> 2012-11-26 20:14:55 PST ---
(In reply to comment #12)
> (In reply to comment #11)

OK. I understood that Manu says. And my yesterday comment was completely wrong. Sorry for my misunderstanding.

Certainly, isFunction is an important template which lacks in std.traits. Existing other function traits, isSomeFunction, isCallble, FunctionTypeOf, return true even if given function pointer or delegate. I can agree with the behavior is sometimes obstacle.

> Blending traits about type and symbol is not a purpose of std.traits.

And more, mixing symbol and type is *a design* of std.traits. I had misunderstood at the point. isSomeFunction is an example.

  /**
  Detect whether >>symbol or type<< $(D T) is a function, a function pointer
  or a delegate.
   */
  template isSomeFunction(T...) { ... }

I challenged implementing proposed template isVariable. Is this what you want?

https://gist.github.com/4152297

-- 
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 #21 from Manu <turkeyman@gmail.com> 2012-11-26 23:24:17 PST ---
(In reply to comment #20)
> (In reply to comment #12)
> > (In reply to comment #11)
> 
> OK. I understood that Manu says. And my yesterday comment was completely wrong. Sorry for my misunderstanding.
> 
> Certainly, isFunction is an important template which lacks in std.traits. Existing other function traits, isSomeFunction, isCallble, FunctionTypeOf, return true even if given function pointer or delegate. I can agree with the behavior is sometimes obstacle.
> 
> > Blending traits about type and symbol is not a purpose of std.traits.
> 
> And more, mixing symbol and type is *a design* of std.traits. I had misunderstood at the point. isSomeFunction is an example.
> 
>   /**
>   Detect whether >>symbol or type<< $(D T) is a function, a function pointer
>   or a delegate.
>    */
>   template isSomeFunction(T...) { ... }
> 
> I challenged implementing proposed template isVariable. Is this what you want?
> 
> https://gist.github.com/4152297

It looks good, although I can't test it now.
Does isVariable deal with properties (which I would say are NOT variables). And
how about an isProperty? That's really hard to detect...

I'm not sold on the term isManifestConstant, I'm sure no non-compiler developer would have ever heard that term before. I've never seen it in any docs before, and they're declared with 'enum', that's what most people will call it.

-- 
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 #22 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-11-26 23:36:52 PST ---
> I'm not sold on the term isManifestConstant, I'm sure no non-compiler developer would have ever heard that term before. I've never seen it in any docs before, and they're declared with 'enum', that's what most people will call it.

I don't know if isManifestConstant is the best name, but it's the official term, and I'm sure that a large portion of the regular newsgroup goers know what it is, not just the compiler devs. I don't know how many outside that group would know it however. Still, given that it's the official name, and that we don't really _have_ another name, I think that I'd still be in favor of isManifestConstant. And if we have isManifestConstant and isEnumType and no isEnum, then we avoid all of the confusion surrounding what exactly an enum is. And it's not like it will be hard for the docs to explain the terms.

-- 
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 #23 from Kenji Hara <k.hara.pg@gmail.com> 2012-11-26 23:46:48 PST ---
(In reply to comment #21)
> (In reply to comment #20)
> > I challenged implementing proposed template isVariable. Is this what you want?
> > 
> > https://gist.github.com/4152297
> 
> It looks good, although I can't test it now.
> Does isVariable deal with properties (which I would say are NOT variables). And
> how about an isProperty? That's really hard to detect...

Added isPropertyFunction (isProperty is a bit ambiguous name to me). I think it's a trait derived from isFunction.

> I'm not sold on the term isManifestConstant, I'm sure no non-compiler developer would have ever heard that term before. I've never seen it in any docs before, and they're declared with 'enum', that's what most people will call it.

http://dlang.org/features2.html
> Extended enums to allow declaration of manifest constants.

http://dlang.org/enum.html
> Manifest Constants
>  If there is only one member of an anonymous enum, the { } can be omitted:
>  [snip]
>  Such declarations are not lvalues, meaning their address cannot be taken.

-- 
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 #24 from Manu <turkeyman@gmail.com> 2012-11-27 03:57:58 PST ---
(In reply to comment #22)
> > I'm not sold on the term isManifestConstant, I'm sure no non-compiler developer would have ever heard that term before. I've never seen it in any docs before, and they're declared with 'enum', that's what most people will call it.
> 
> I don't know if isManifestConstant is the best name, but it's the official term, and I'm sure that a large portion of the regular newsgroup goers know what it is, not just the compiler devs. I don't know how many outside that group would know it however. Still, given that it's the official name, and that we don't really _have_ another name, I think that I'd still be in favor of isManifestConstant. And if we have isManifestConstant and isEnumType and no isEnum, then we avoid all of the confusion surrounding what exactly an enum is. And it's not like it will be hard for the docs to explain the terms.

There is another name, it's called an 'enum', as clearly stated by the syntax:
enum x = 10;
Using any term other than that seems crazy by my measure. The user base aren't
compiler developers. I don't even know what manifest means.

I don't think the distinction isEnumType, isEnumValue is at all confusing, in fact, the function names alone document the important detail that there IS a distinction, and what it is.


(In reply to comment #23)
> (In reply to comment #21)
> > (In reply to comment #20)
> > > I challenged implementing proposed template isVariable. Is this what you want?
> > > 
> > > https://gist.github.com/4152297
> > 
> > It looks good, although I can't test it now.
> > Does isVariable deal with properties (which I would say are NOT variables). And
> > how about an isProperty? That's really hard to detect...
> 
> Added isPropertyFunction (isProperty is a bit ambiguous name to me). I think it's a trait derived from isFunction.

This highlights another conflict in terminology, currently a property is NOT recognised as a function (at least in my crappy tests). I really think isFunction!someProperty should be true. It's a function, exactly like any other, I can take pointers/delegates of it, it just has a particular usage semantic. Effectively a subset, not a different concept.

So I suggest isFunction! should give true for a property function definition.

> > I'm not sold on the term isManifestConstant, I'm sure no non-compiler developer would have ever heard that term before. I've never seen it in any docs before, and they're declared with 'enum', that's what most people will call it.
> 
> http://dlang.org/features2.html
> > Extended enums to allow declaration of manifest constants.

This clearly implies that 'manifest constant' is in fact some kind of enum.

> http://dlang.org/enum.html
> > Manifest Constants
> >  If there is only one member of an anonymous enum, the { } can be omitted:
> >  [snip]
> >  Such declarations are not lvalues, meaning their address cannot be taken.

Again, referring to 'anonymous enum', it's not distancing its self from the enum terminology.

...

I just asked 2 other programmers in the room what enum x = 10; is, they said it's an enum, not a manifest constant ;)

None of them could tell me what a manifest constant it, or that they'd ever heard of such a thing before.

But I don't actually care at the end of the day, I'm just trying to give a voice of reason. What the compiler calls stuff internally has no bearing on what users of the language will call things. The user facing library should endeavour to match the terminology used by the users IMO.

-- 
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 #25 from Manu <turkeyman@gmail.com> 2012-11-27 04:06:02 PST ---
(In reply to comment #24)
> This highlights another conflict in terminology, currently a property is NOT recognised as a function (at least in my crappy tests). I really think isFunction!someProperty should be true. It's a function, exactly like any other, I can take pointers/delegates of it, it just has a particular usage semantic. Effectively a subset, not a different concept.
> 
> So I suggest isFunction! should give true for a property function definition.

Sorry! I just saw your unit test asserts isFunction! is true for property functions. I didn't see that behaviour with is(X==function) in my tests.

-- 
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 #26 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-11-27 04:14:28 PST ---
(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

-- 
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 #27 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-11-27 04:15:48 PST ---
(In reply to comment #26)
> Anyway it's documented behavior, see "manifest constants" here (it's at the bottom): http://dlang.org/enum.html

Actually it's poorly documented, it speaks about "anon" enums but it shouldn't really mention them at all imo.

-- 
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 #28 from Jacob Carlborg <doob@me.com> 2012-11-27 04:41:46 PST ---
(In reply to comment #26)

> 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.

Isn't the whole problem that the compiler and/or linker isn't capable of stripping out symbols that are only used at compile time.

-- 
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 #29 from Manu <turkeyman@gmail.com> 2012-11-27 04:51:33 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.

I couldn't disagree more.

Firstly, what it is clearly documented as, is being some subset of enum. That's what it 'really is'.

More importantly, if I look at the top of std.traits for something I presume to be called isEnum, and I see isEnumValue, I'll realise that's actually what I'm looking for immediately, use it, and save myself time.

If I see something called isEnum, and it doesn't seem to work because it only reports true for enum TYPES (not values), then I'll declare it broken and report a bug.

If I scan through everything in std.traits, and find nothing that looks like what I want, I'll get frustrated the thing I need is missing.

If I see isManifestConstant, there is _NO WAY_ I would have even read what that is, it's clearly not what I'm looking for, I'm trying to identify if my thing is an enum...


> 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.

I honestly don't even know what manifest means. The terminology used in the syntax and the documentation is correct; it's a kind of enum.


> Anyway it's documented behavior, see "manifest constants" here (it's at the bottom): http://dlang.org/enum.html

And every place it appears, it is clearly defined as being some subset of enum.

Again, if I go looking for isEnum, and find a suite of more specific enum related traits (isEnumType, isEnumValue), I can easily conclude which is the one I'm looking for. If the name is completely unrelated and uses terminology most programmers have never heard before, they'll never spot it.


As a side point, what do you call X in: enum E { X = 10 } ?

Consider:
 enum E { X = 10 }
 enum Y = 10;

E.X and Y are both identical as far as I can tell. I would presume:

isEnumType!E == true, and isEnumValue!(E.X) == isEnumValue!Y == true.
You can tweak the names, but I think traits to that effect are a) useful, b)
what (I presume) most typical users will expect.

E.X and Y are identical. I think this specialised term 'manifest constant' that only applies to Y can only result in confusion.

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