[Issue 9065] Please consider adding these std.traits

[d-bugmail at puremagic.com]

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



--- Comment #24 from Manu <turkeyman at 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: -------