Bug 3702 – Replace __traits and is(typeof()) with a 'magic namespace'

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)

Currently this is the most voted Bugzilla bug (enhancement request).

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.

NG Threads: * [phobos] More tuple algorithms with std.meta http://forum.dlang.org/thread/[email protected] * RFC: StaticFilter, PApply, Compose, template predicates http://forum.dlang.org/thread/[email protected] 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

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

This is going to superseded by forthcoming DIP on consistent introspection, similar ideas actually. This scale of change is only possible as DIP.