www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3702] New: Replace __traits and is(typeof()) with a 'magic namespace'

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3702

           Summary: Replace __traits and is(typeof()) with a 'magic
                    namespace'
           Product: D
           Version: future
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bugzilla kyllingen.net


--- Comment #0 from Lars T. Kyllingstad <bugzilla kyllingen.net> 2010-01-13
06:46:44 PST ---
This proposal was formulated by Don in the NG post at:
http://www.digitalmars.com/d/archives/digitalmars/D/Proposal_Replace_traits_and_is_typeof_XXX_with_a_magic_namespace_._99914.html

I repost it here because I think it is important. Quoting Don's proposal:

---

is(typeof(XXX)) is infamously ugly and unintuitive
__traits(compiles, XXX) is more comprehensible, but just as ugly.

They are giving metaprogramming in D a bad name. I think we need to get rid of
both of them.

A very easy way of doing this is to replace them with a 'magic namespace' -- so
that they _look_ as though they're functions in a normal module.
Names which have been suggested include 'meta', 'traits', 'scope', 'compiler'.
Personally I think 'meta' is the nicest (and I suggested two of the others
<g>). This would give us:

meta.compiles(XXX)
meta.isArithmetic; // note, property syntax OK if no arguments
meta.isArithmetic(int*);

Benefits:
* Fewer keywords: __traits -> meta, typeid() -> meta.typeid()
* Get rid of is() expressions, which are the most complicated thing in the
language.
* Some meta.XXX functions could be defined in runtime library code.
* The existing __traits functions could have more useful return values.
* Retain the flexibility of __traits.

--- (quote ends)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 13 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3702


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc


--- Comment #1 from bearophile_hugs eml.cc 2012-01-27 15:54:21 PST ---
Currently this is the most voted Bugzilla bug (enhancement request).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 27 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3702


Leandro Lucarella <leandro.lucarella sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |leandro.lucarella sociomant
                   |                            |ic.com


--- Comment #2 from Leandro Lucarella <leandro.lucarella sociomantic.com>
2012-05-31 04:41:09 PDT ---
Now is the second and no news about if this is ever intended to be implemented.
It would be nice to have an "official" word saying if is something that should
be in the language eventually or if it should be closed as WONTFIX.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 31 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3702


Denis Shelomovskij <verylonglogin.reg gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |verylonglogin.reg gmail.com


--- Comment #3 from Denis Shelomovskij <verylonglogin.reg gmail.com> 2012-06-04
14:28:17 MSD ---
NG Threads:
* [phobos] More tuple algorithms with std.meta
http://forum.dlang.org/thread/j3uhpu$285b$1 digitalmars.com

* RFC: StaticFilter, PApply, Compose, template predicates
http://forum.dlang.org/thread/j3uhpu$285b$1 digitalmars.com

Sources:
* std.meta by Shin Fujishiro
Huge, the last commit was 18 Nov 2010.
https://github.com/sinfu/phobos-sandbox
Fork: https://github.com/9rnsr/std_meta_fork

* stdd.typetuple by Denis Shelomovskij:
Small (with only the most needed features) but with some things done right
(staticNot and UnaryPred).
https://bitbucket.org/denis_sh/misc/src/tip/stdd/typetuple.d

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 04 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3702


Nick Treleaven <ntrel-public yahoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ntrel-public yahoo.co.uk


--- Comment #4 from Nick Treleaven <ntrel-public yahoo.co.uk> 2013-07-16
07:29:48 PDT ---
(In reply to comment #0)
 is(typeof(XXX)) is infamously ugly and unintuitive
 __traits(compiles, XXX) is more comprehensible, but just as ugly.
 
 They are giving metaprogramming in D a bad name. I think we need to get rid of
 both of them.
...
 meta.compiles(XXX)
 meta.isArithmetic; // note, property syntax OK if no arguments
 meta.isArithmetic(int*);
I support this, but I think using template instantiation syntax might be even better, to help avoid brackets for simple cases: meta.isArithmetic!int meta.isArithmetic!(i, i+1) meta.isArithmetic // could be OK, otherwise append !() meta.parent!T meta.typeid!x For simple code snippets, brackets as proposed don't seem too bad. But we know how much nesting often happens in complex code, and eliminating brackets in a complex expression is a clear win for readability. __traits(compiles, ...) must be the most commonly used trait, and I think it's very often used with nullary delegate literals. So I also propose this special case: meta.compiles!{...} Here, the () brackets after '!' are not required because the braces are enough. compare with: meta.compiles({...}) __traits(compiles, {...}) is(typeof({...})) It would be really nice to have 'meta' as a keyword, it could also be used for manifest constants, instead of enum: meta five = 5; But people may already be using the identifier 'meta', e.g. in a module name, xtd.meta. Perhaps we should make meta a 'soft' reserved word. I.e. it is allowed as an identifier, but the compiler prints a message 'Note: meta may become a reserved word in later versions'. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 16 2013