www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - __traits so long and ugly, what about ::?

reply Ary Manzana <ary esperanto.org.ar> writes:
I think :: is not used in the language.

In a recent article about D I saw:

mixin(__traits(identifier, T) ~ " " ~
       to!string(tolower(__traits(identifier, T)[0])) ~
       __traits(identifier, T)[1..$] ~ ";");

What if foo::bar were an alias for __traits(foo, bar) ?

The code would look like this:

mixin(T::identifier ~ " " ~
       to!string(tolower(T::identifier[0])) ~
       T::identifier[1..$] ~ ";");

What do you think?

Another uses:

__traits(int, isArithmetic) ==> int::isArithmetic
__traits(C, isAbstractClass) ==> C::isAbstractClass

__traits(hasMember, S, "m") ==> S::hasMember("m")

Well, you get the idea...

:: might be applied to other compile time uses, but I just came up with 
this...
Mar 30 2011
next sibling parent reply David Nadlinger <see klickverbot.at> writes:
You are not the only one to find __traits ugly – although not directly 
related to your question, it has been proposed several times to ditch 
is(typeof()) and __traits and replace them with a magic »meta« 
namespace. There is even a bug report about it: 
http://d.puremagic.com/issues/show_bug.cgi?id=3702

David
Mar 30 2011
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/30/11 4:32 PM, David Nadlinger wrote:

 You are not the only one to find __traits ugly – although not directly
 related to your question, it has been proposed several times to ditch
 is(typeof()) and __traits and replace them with a magic »meta«
 namespace. There is even a bug report about it:
 http://d.puremagic.com/issues/show_bug.cgi?id=3702

 David


David, thanks for the answer. I am aware of that proposal, but I don't 
like it because it's not very readble. You have to read "meta 
isArithmetic int", kind of like how yoda speaks, but in the other case, 
"int::isArithmetic" is much more natural and shorter and nicer.

I'm just suggesting a syntax for accessing compile-time things. It seems 
:: is unused...
Mar 30 2011
parent "Nick Sabalausky" <a a.a> writes:
"Ary Manzana" <ary esperanto.org.ar> wrote in message 
news:in0169$5sb$1 digitalmars.com...

 On 3/30/11 4:32 PM, David Nadlinger wrote:

 You are not the only one to find __traits ugly - although not directly
 related to your question, it has been proposed several times to ditch
 is(typeof()) and __traits and replace them with a magic »meta«
 namespace. There is even a bug report about it:
 http://d.puremagic.com/issues/show_bug.cgi?id=3702

 David


 David, thanks for the answer. I am aware of that proposal, but I don't 
 like it because it's not very readble. You have to read "meta isArithmetic 
 int", kind of like how yoda speaks, but in the other case, 
 "int::isArithmetic" is much more natural and shorter and nicer.

 I'm just suggesting a syntax for accessing compile-time things. It seems 
 :: is unused...


I've always felt the meta namespace should be member-call syntax: 
int.meta.whatever

Your suggestion is a nice shortcut to that, though.
Mar 30 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 31, 11 03:28, Ary Manzana wrote:

 I think :: is not used in the language.

 In a recent article about D I saw:

 mixin(__traits(identifier, T) ~ " " ~
 to!string(tolower(__traits(identifier, T)[0])) ~
 __traits(identifier, T)[1..$] ~ ";");

 What if foo::bar were an alias for __traits(foo, bar) ?

 The code would look like this:

 mixin(T::identifier ~ " " ~
 to!string(tolower(T::identifier[0])) ~
 T::identifier[1..$] ~ ";");

 What do you think?

 Another uses:

 __traits(int, isArithmetic) ==> int::isArithmetic
 __traits(C, isAbstractClass) ==> C::isAbstractClass


You've got the order wrong.


 __traits(hasMember, S, "m") ==> S::hasMember("m")

 Well, you get the idea...

 :: might be applied to other compile time uses, but I just came up with
 this...


-1.

This is confusing as :: is used to separate scopes in C++ (and PHP too). 
e.g.

     struct A {
        int x;
        bool isSame(const A other) pure const { return x == other.x; }
     }

     void main () {
        A a = A(2), b = A(2);
        assert (  a.isSame(b));   // ok
        assert (! a::isSame(b));  // ???
     }

(How about that 'meta' namespace proposal? meta.hasMember(S, "m") )
Mar 30 2011
next sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 30/03/2011 20:45, KennyTM~ wrote:

 This is confusing as :: is used to separate scopes in C++ (and PHP too).


The first thing it reminded me of was Lua, where a single colon makes 
the left hand side into the first argument of the function on the right.

foo:bar(x) ==> bar.(foo, x)

So it felt kinda familiar to me ^^

A...
Mar 30 2011
parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 31, 11 04:19, Alix Pexton wrote:

 On 30/03/2011 20:45, KennyTM~ wrote:

 This is confusing as :: is used to separate scopes in C++ (and PHP too).


 The first thing it reminded me of was Lua, where a single colon makes
 the left hand side into the first argument of the function on the right.

 foo:bar(x) ==> bar.(foo, x)

 So it felt kinda familiar to me ^^

 A...


That is almost like UFCS in D.

     int foo(string x, int y) { return x.length - y; }

     assert (foo("testing", 3) == 4);
     assert ("testing".foo(3) == 4);

But OP's proposal is restricted to __traits only.

__traits is a relatively advanced part of the language, plus many of its 
features has already been exposed via the library std.traits, e.g. 
std.traits.hasMember!(S, "m"), I don't think it really needs a very 
short syntax.
Mar 30 2011
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/30/11 5:52 PM, KennyTM~ wrote:

 On Mar 31, 11 04:19, Alix Pexton wrote:

 On 30/03/2011 20:45, KennyTM~ wrote:

 This is confusing as :: is used to separate scopes in C++ (and PHP too).


 The first thing it reminded me of was Lua, where a single colon makes
 the left hand side into the first argument of the function on the right.

 foo:bar(x) ==> bar.(foo, x)

 So it felt kinda familiar to me ^^

 A...


 That is almost like UFCS in D.

 int foo(string x, int y) { return x.length - y; }

 assert (foo("testing", 3) == 4);
 assert ("testing".foo(3) == 4);

 But OP's proposal is restricted to __traits only.

 __traits is a relatively advanced part of the language, plus many of its
 features has already been exposed via the library std.traits, e.g.
 std.traits.hasMember!(S, "m"), I don't think it really needs a very
 short syntax.


Look, metaprogramming in Ruby is a relatively advanced part of the 
language. And you know why it is heavily used and everyone can jump and 
start using it in a matter of seconds and build the most amazing things? 
Because it's very, very, very, (add 1000 very words here), very easy to use.

Why make *anything* hard to use if you can do it in an easier way?
Mar 30 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Ary Manzana:


 Why make *anything* hard to use if you can do it in an easier way?


I agree. On the other hand is the :: syntax easy compared to a "meta."
namespace? The meta name is more readable. I suggest to try to invent few more
alternative syntaxes before choosing.

Bye,
bearophile
Mar 30 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
How about not inventing new syntaxes? Leave that to C++7xFF.
Mar 30 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 How about not inventing new syntaxes? Leave that to C++7xFF.


Sorry for not being clear, by "alternative syntaxes" I meant something like the
"meta" namespace too.

Bye,
bearophile
Mar 30 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 31, 11 06:32, Ary Manzana wrote:

 On 3/30/11 5:52 PM, KennyTM~ wrote:

 On Mar 31, 11 04:19, Alix Pexton wrote:

 On 30/03/2011 20:45, KennyTM~ wrote:

 This is confusing as :: is used to separate scopes in C++ (and PHP
 too).


 The first thing it reminded me of was Lua, where a single colon makes
 the left hand side into the first argument of the function on the right.

 foo:bar(x) ==> bar.(foo, x)

 So it felt kinda familiar to me ^^

 A...


 That is almost like UFCS in D.

 int foo(string x, int y) { return x.length - y; }

 assert (foo("testing", 3) == 4);
 assert ("testing".foo(3) == 4);

 But OP's proposal is restricted to __traits only.

 __traits is a relatively advanced part of the language, plus many of its
 features has already been exposed via the library std.traits, e.g.
 std.traits.hasMember!(S, "m"), I don't think it really needs a very
 short syntax.


 Look, metaprogramming in Ruby is a relatively advanced part of the
 language. And you know why it is heavily used and everyone can jump and
 start using it in a matter of seconds and build the most amazing things?
 Because it's very, very, very, (add 1000 very words here), very easy to
 use.


We're talking about __traits, a feature for compile-time reflection 
where most of its capability is already wrapped up to std.traits. It 
isn't comparable with the whole metaprogramming capability in another 
language.

You know, metaprogramming is also heavily used in D, because of a 
sensible template system, mixins and CTFE, not __traits.


 Why make *anything* hard to use if you can do it in an easier way?


Is

   meta.hasMember(S, "m")

or even

   import std.traits;
   ...
   hasMember!(S, "m")

really that hard to use?

I think the 'meta' namespace is enough. 'A::B' is too much for such a 
low-level feature.
Mar 30 2011
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
I just hate it when you have to write too much to get simple things
done.

Does this type have a member? Current approach:

1. import std.traits;
2. invoke hasMember!(S, "m")

Another approach:

1. I have the type, let's ask it: S::hasMember("m")

Map's thought to code.

My problem is that when you start using D's cool features you end up
with a really hard to understand and obscure code...
Mar 30 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 31, 11 09:42, Ary Manzana wrote:

 I just hate it when you have to write too much to get simple things
 done.

 Does this type have a member? Current approach:

 1. import std.traits;
 2. invoke hasMember!(S, "m")

 Another approach:

 1. I have the type, let's ask it: S::hasMember("m")

 Map's thought to code.

 My problem is that when you start using D's cool features you end up
 with a really hard to understand and obscure code...


How often do you really needs feature in __traits? I've grepped my code 
which uses a lot of templates and CTFE, and it only appears in 2 lines

     else static if (__traits(isScalar, T)) {
         static if (__traits(compiles, T.init.re))

Therefore I oppose the use of :: just for __traits, because it's so rare.

Now I have a counter-proposal,

     T::ident(x, y, z, ...)  <=>  ident!(T, x, y, z, ...)

then hasMember can be invoked as

     import std.traits;
     ...
     S::hasMember("m")

Isn't it better than reserving :: just for __traits?
Mar 30 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-30 19:38, KennyTM~ wrote:

 On Mar 31, 11 09:42, Ary Manzana wrote:

 I just hate it when you have to write too much to get simple things
 done.
 
 Does this type have a member? Current approach:
 
 1. import std.traits;
 2. invoke hasMember!(S, "m")
 
 Another approach:
 
 1. I have the type, let's ask it: S::hasMember("m")
 
 Map's thought to code.
 
 My problem is that when you start using D's cool features you end up
 with a really hard to understand and obscure code...


 
 How often do you really needs feature in __traits? I've grepped my code
 which uses a lot of templates and CTFE, and it only appears in 2 lines
 
      else static if (__traits(isScalar, T)) {
          static if (__traits(compiles, T.init.re))
 
 Therefore I oppose the use of :: just for __traits, because it's so rare.
 
 Now I have a counter-proposal,
 
      T::ident(x, y, z, ...)  <=>  ident!(T, x, y, z, ...)
 
 then hasMember can be invoked as
 
      import std.traits;
      ...
      S::hasMember("m")
 
 Isn't it better than reserving :: just for __traits?


I use __traits(compiles, ) all the time, and a few of the others in __traits, 
though I probably use std.traits more than __traits.

I don't mind the meta proposal (__traits _is_ kind of ugly), but I 
_definitely_ don't like the :: proposal. I don't find it to be clear at all, 
and it's one more operator to remember. Not to mention, it might cause 
problems when porting C++ code.

- Jonathan M Davis
Mar 30 2011
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
On Mar 31, 11 10:38, KennyTM~ wrote:

 On Mar 31, 11 09:42, Ary Manzana wrote:

 I just hate it when you have to write too much to get simple things
 done.

 Does this type have a member? Current approach:

 1. import std.traits;
 2. invoke hasMember!(S, "m")

 Another approach:

 1. I have the type, let's ask it: S::hasMember("m")

 Map's thought to code.

 My problem is that when you start using D's cool features you end up
 with a really hard to understand and obscure code...


 How often do you really needs feature in __traits? I've grepped my code
 which uses a lot of templates and CTFE, and it only appears in 2 lines

 else static if (__traits(isScalar, T)) {
 static if (__traits(compiles, T.init.re))

 Therefore I oppose the use of :: just for __traits, because it's so rare.

 Now I have a counter-proposal,

 T::ident(x, y, z, ...) <=> ident!(T, x, y, z, ...)

 then hasMember can be invoked as

 import std.traits;
 ...
 S::hasMember("m")

 Isn't it better than reserving :: just for __traits?


PS. I don't mean to push this proposal. This is just to show that 
instead of using :: for __traits, there is a better alternative.
Mar 30 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/30/11 8:42 PM, Ary Manzana wrote:

 I just hate it when you have to write too much to get simple things
 done.

 Does this type have a member? Current approach:

 1. import std.traits;
 2. invoke hasMember!(S, "m")

 Another approach:

 1. I have the type, let's ask it: S::hasMember("m")

 Map's thought to code.

 My problem is that when you start using D's cool features you end up
 with a really hard to understand and obscure code...


I understand and to a good extent agree with the sentiment.

However, right now GSoC with student proposals to attract and review, an 
undergoing Phobos proposal review, one or a couple more waiting in the 
queue, good progress in core areas (64 bit stabilization, rigorous 
deterministic destruction, important bug fixes, and to follow the 
immutability subsystem and shared libraries) I can't stop feeling many 
of such discussions do more harm than good. There's always a better way 
to express a frequent idiom, and we may as well adopt one later. But 
this is the time to act, and there's plenty to act on.

Let's focus on getting real work done. This is the D Summer of Code. :o)


Andrei
Mar 30 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 31, 11 11:24, Andrei Alexandrescu wrote:

 On 3/30/11 8:42 PM, Ary Manzana wrote:

 I just hate it when you have to write too much to get simple things
 done.

 Does this type have a member? Current approach:

 1. import std.traits;
 2. invoke hasMember!(S, "m")

 Another approach:

 1. I have the type, let's ask it: S::hasMember("m")

 Map's thought to code.

 My problem is that when you start using D's cool features you end up
 with a really hard to understand and obscure code...


 I understand and to a good extent agree with the sentiment.

 However, right now GSoC with student proposals to attract and review, an
 undergoing Phobos proposal review, one or a couple more waiting in the
 queue, good progress in core areas (64 bit stabilization, rigorous
 deterministic destruction, important bug fixes, and to follow the
 immutability subsystem and shared libraries) I can't stop feeling many
 of such discussions do more harm than good. There's always a better way
 to express a frequent idiom, and we may as well adopt one later. But
 this is the time to act, and there's plenty to act on.

 Let's focus on getting real work done. This is the D Summer of Code. :o)


 Andrei


I think the GSoC group and language feature discussion group should be 
separated.
Mar 30 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/30/2011 10:30 PM, KennyTM~ wrote:

 On Mar 31, 11 11:24, Andrei Alexandrescu wrote:

 On 3/30/11 8:42 PM, Ary Manzana wrote:

 I just hate it when you have to write too much to get simple things
 done.

 Does this type have a member? Current approach:

 1. import std.traits;
 2. invoke hasMember!(S, "m")

 Another approach:

 1. I have the type, let's ask it: S::hasMember("m")

 Map's thought to code.

 My problem is that when you start using D's cool features you end up
 with a really hard to understand and obscure code...


 I understand and to a good extent agree with the sentiment.

 However, right now GSoC with student proposals to attract and review, an
 undergoing Phobos proposal review, one or a couple more waiting in the
 queue, good progress in core areas (64 bit stabilization, rigorous
 deterministic destruction, important bug fixes, and to follow the
 immutability subsystem and shared libraries) I can't stop feeling many
 of such discussions do more harm than good. There's always a better way
 to express a frequent idiom, and we may as well adopt one later. But
 this is the time to act, and there's plenty to act on.

 Let's focus on getting real work done. This is the D Summer of Code. :o)


 Andrei


 I think the GSoC group and language feature discussion group should be
 separated.


That makes sense, but I'd rather encourage our limited regular 
participants to use their limited time on constructive discussions that 
address needs both important and urgent. That would be a lot better than 
spreading ourselves too thin.

Andrei
Mar 30 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:


 I think the GSoC group and language feature discussion group should be 
 separated.


Regarding D/Phobos feature discussions, they don't damage the summer of code
discussions significantly because they put in use almost a different part of
the brain. The skills and attention required to write real code (or discuss
closely about it, like discussion about what data structures to write down for
the GSoC) are quite different from the skills needed to think about new design
ideas for D or Phobos. For me such two things are so separated that I use one
to relax my mind from doing the other too much.

Said that, and given the limited number of people here, a further newsgroup
split is not good.

Bye,
bearophile
Mar 31 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/31/2011 03:52 AM, bearophile wrote:

 KennyTM~:


 I think the GSoC group and language feature discussion group should
 be separated.


 Regarding D/Phobos feature discussions, they don't damage the summer
 of code discussions significantly because they put in use almost a
 different part of the brain.


They do share the same time budget.

Andrei
Mar 31 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 31 Mar 2011 10:16:58 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 03/31/2011 03:52 AM, bearophile wrote:

 KennyTM~:


 I think the GSoC group and language feature discussion group should
 be separated.


 Regarding D/Phobos feature discussions, they don't damage the summer
 of code discussions significantly because they put in use almost a
 different part of the brain.


 They do share the same time budget.


So don't read/respond to the posts.  I think any discouragement for open  
discussion for any topic related to D is not a healthy attitude for an  
open community.

If you want to have a GSOC-only discussion group, create a new newsgroup  
or mailing list.  Do not hijack this group.

-Steve
Mar 31 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/31/2011 09:27 AM, Steven Schveighoffer wrote:

 On Thu, 31 Mar 2011 10:16:58 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 03/31/2011 03:52 AM, bearophile wrote:

 KennyTM~:


 I think the GSoC group and language feature discussion group should
 be separated.


 Regarding D/Phobos feature discussions, they don't damage the summer
 of code discussions significantly because they put in use almost a
 different part of the brain.


 They do share the same time budget.


 So don't read/respond to the posts. I think any discouragement for open
 discussion for any topic related to D is not a healthy attitude for an
 open community.


Well you know it's considerably less simpler than that. Besides, I 
probably wasn't clear enough: I'm not discouraging anything as much as 
encouraging discussions that mark progress in important matters.


 If you want to have a GSOC-only discussion group, create a new newsgroup
 or mailing list. Do not hijack this group.


This is not about GSoC (it's but one of several items I mentioned), it's 
simply about making headway in topics that are important.


Andrei
Mar 31 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 31 Mar 2011 10:39:29 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 03/31/2011 09:27 AM, Steven Schveighoffer wrote:

 On Thu, 31 Mar 2011 10:16:58 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 03/31/2011 03:52 AM, bearophile wrote:

 KennyTM~:


 I think the GSoC group and language feature discussion group should
 be separated.


 Regarding D/Phobos feature discussions, they don't damage the summer
 of code discussions significantly because they put in use almost a
 different part of the brain.


 They do share the same time budget.


 So don't read/respond to the posts. I think any discouragement for open
 discussion for any topic related to D is not a healthy attitude for an
 open community.


 Well you know it's considerably less simpler than that. Besides, I  
 probably wasn't clear enough: I'm not discouraging anything as much as  
 encouraging discussions that mark progress in important matters.


That's a better statement.  I just don't think such "unimportant"  
discussions are harmful or damaging, just don't participate if you don't  
want to be distracted.  We're all (mostly) adults in charge of our own  
schedule.  We don't need to be insulated from things.


 If you want to have a GSOC-only discussion group, create a new newsgroup
 or mailing list. Do not hijack this group.


 This is not about GSoC (it's but one of several items I mentioned), it's  
 simply about making headway in topics that are important.


Sorry if I got the wrong impression.  I don't always read an entire thread  
when I see a post I want to respond to.

-Steve
Mar 31 2011
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 31/03/2011 16:11, Steven Schveighoffer wrote:

 On Thu, 31 Mar 2011 10:39:29 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 03/31/2011 09:27 AM, Steven Schveighoffer wrote:

 On Thu, 31 Mar 2011 10:16:58 -0400, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:


 On 03/31/2011 03:52 AM, bearophile wrote:

 KennyTM~:


 I think the GSoC group and language feature discussion group should
 be separated.


 Regarding D/Phobos feature discussions, they don't damage the summer
 of code discussions significantly because they put in use almost a
 different part of the brain.


 They do share the same time budget.


 So don't read/respond to the posts. I think any discouragement for open
 discussion for any topic related to D is not a healthy attitude for an
 open community.


 Well you know it's considerably less simpler than that. Besides, I
 probably wasn't clear enough: I'm not discouraging anything as much as
 encouraging discussions that mark progress in important matters.


 That's a better statement. I just don't think such "unimportant"
 discussions are harmful or damaging, just don't participate if you don't
 want to be distracted. We're all (mostly) adults in charge of our own
 schedule. We don't need to be insulated from things.


Yeah, kinda, but the thing is that such discussions are often done 
carrying the posture or tone that the language/compiler/library writers 
should work or address that issue soon (or even in the medium-term). 
That's perhaps what's most frustrating.


-- 
Bruno Medeiros - Software Engineer
Apr 07 2011
prev sibling parent spir <denis.spir gmail.com> writes:
On 03/31/2011 05:24 AM, Andrei Alexandrescu wrote:

 My problem is that when you start using D's cool features you end up
 with a really hard to understand and obscure code...


 I understand and to a good extent agree with the sentiment.


Pleased to read that :-) I've had this sentiment for a while as well. I'm 
afraid this is frightening. Large pieces of Phobos are hard to read, imo (eg 
std.format).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Mar 31 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-03-31 01:05, KennyTM~ wrote:

 On Mar 31, 11 06:32, Ary Manzana wrote:

 On 3/30/11 5:52 PM, KennyTM~ wrote:

 On Mar 31, 11 04:19, Alix Pexton wrote:

 On 30/03/2011 20:45, KennyTM~ wrote:

 This is confusing as :: is used to separate scopes in C++ (and PHP
 too).


 The first thing it reminded me of was Lua, where a single colon makes
 the left hand side into the first argument of the function on the
 right.

 foo:bar(x) ==> bar.(foo, x)

 So it felt kinda familiar to me ^^

 A...


 That is almost like UFCS in D.

 int foo(string x, int y) { return x.length - y; }

 assert (foo("testing", 3) == 4);
 assert ("testing".foo(3) == 4);

 But OP's proposal is restricted to __traits only.

 __traits is a relatively advanced part of the language, plus many of its
 features has already been exposed via the library std.traits, e.g.
 std.traits.hasMember!(S, "m"), I don't think it really needs a very
 short syntax.


 Look, metaprogramming in Ruby is a relatively advanced part of the
 language. And you know why it is heavily used and everyone can jump and
 start using it in a matter of seconds and build the most amazing things?
 Because it's very, very, very, (add 1000 very words here), very easy to
 use.


 We're talking about __traits, a feature for compile-time reflection
 where most of its capability is already wrapped up to std.traits. It
 isn't comparable with the whole metaprogramming capability in another
 language.

 You know, metaprogramming is also heavily used in D, because of a
 sensible template system, mixins and CTFE, not __traits.


 Why make *anything* hard to use if you can do it in an easier way?


 Is

 meta.hasMember(S, "m")

 or even

 import std.traits;
 ...
 hasMember!(S, "m")

 really that hard to use?

 I think the 'meta' namespace is enough. 'A::B' is too much for such a
 low-level feature.


In Ruby it would just be: S.hasMember("m") and "hasMember" would just be 
a regular plain old method, nothing special about it.

-- 
/Jacob Carlborg
Mar 31 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-03-31 00:32, Ary Manzana wrote:

 On 3/30/11 5:52 PM, KennyTM~ wrote:

 On Mar 31, 11 04:19, Alix Pexton wrote:

 On 30/03/2011 20:45, KennyTM~ wrote:

 This is confusing as :: is used to separate scopes in C++ (and PHP
 too).


 The first thing it reminded me of was Lua, where a single colon makes
 the left hand side into the first argument of the function on the right.

 foo:bar(x) ==> bar.(foo, x)

 So it felt kinda familiar to me ^^

 A...


 That is almost like UFCS in D.

 int foo(string x, int y) { return x.length - y; }

 assert (foo("testing", 3) == 4);
 assert ("testing".foo(3) == 4);

 But OP's proposal is restricted to __traits only.

 __traits is a relatively advanced part of the language, plus many of its
 features has already been exposed via the library std.traits, e.g.
 std.traits.hasMember!(S, "m"), I don't think it really needs a very
 short syntax.


 Look, metaprogramming in Ruby is a relatively advanced part of the
 language. And you know why it is heavily used and everyone can jump and
 start using it in a matter of seconds and build the most amazing things?
 Because it's very, very, very, (add 1000 very words here), very easy to
 use.

 Why make *anything* hard to use if you can do it in an easier way?


Yes, because there is nothing special with how the meta information is 
accessed, just regular methods, no additional language support.

-- 
/Jacob Carlborg
Mar 31 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/30/2011 09:45 PM, KennyTM~ wrote:

 On Mar 31, 11 03:28, Ary Manzana wrote:

 I think :: is not used in the language.

 In a recent article about D I saw:

 mixin(__traits(identifier, T) ~ " " ~
 to!string(tolower(__traits(identifier, T)[0])) ~
 __traits(identifier, T)[1..$] ~ ";");

 What if foo::bar were an alias for __traits(foo, bar) ?

 The code would look like this:

 mixin(T::identifier ~ " " ~
 to!string(tolower(T::identifier[0])) ~
 T::identifier[1..$] ~ ";");

 What do you think?

 Another uses:

 __traits(int, isArithmetic) ==> int::isArithmetic
 __traits(C, isAbstractClass) ==> C::isAbstractClass


 You've got the order wrong.


?


 __traits(hasMember, S, "m") ==> S::hasMember("m")

 Well, you get the idea...

 :: might be applied to other compile time uses, but I just came up with
 this...


 -1.

 This is confusing as :: is used to separate scopes in C++ (and PHP too). e.g.


D is not C++. D precisely exists to make things differently, ie its own way.


 struct A {
 int x;
 bool isSame(const A other) pure const { return x == other.x; }
 }

 void main () {
 A a = A(2), b = A(2);
 assert ( a.isSame(b)); // ok
 assert (! a::isSame(b)); // ???
 }

 (How about that 'meta' namespace proposal? meta.hasMember(S, "m") )


This is no improvement about __traits. I'm all for a meta namespace, but it 
should be syntactically attractive. There is no contradiction between Ary's 
proposal meta, though the exact optimal syntax may not be that one.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Mar 30 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 3/30/11 9:45 PM, KennyTM~ wrote:

 On Mar 31, 11 03:28, Ary Manzana wrote:

 I think :: is not used in the language.

 In a recent article about D I saw:

 mixin(__traits(identifier, T) ~ " " ~
 to!string(tolower(__traits(identifier, T)[0])) ~
 __traits(identifier, T)[1..$] ~ ";");

 What if foo::bar were an alias for __traits(foo, bar) ?

 The code would look like this:

 mixin(T::identifier ~ " " ~
 to!string(tolower(T::identifier[0])) ~
 T::identifier[1..$] ~ ";");

 What do you think?

 Another uses:

 __traits(int, isArithmetic) ==> int::isArithmetic
 __traits(C, isAbstractClass) ==> C::isAbstractClass


 You've got the order wrong.


 __traits(hasMember, S, "m") ==> S::hasMember("m")

 Well, you get the idea...

 :: might be applied to other compile time uses, but I just came up with
 this...


 -1.

 This is confusing as :: is used to separate scopes in C++ (and PHP too).
 e.g.

 struct A {
 int x;
 bool isSame(const A other) pure const { return x == other.x; }
 }

 void main () {
 A a = A(2), b = A(2);
 assert ( a.isSame(b)); // ok
 assert (! a::isSame(b)); // ???
 }

 (How about that 'meta' namespace proposal? meta.hasMember(S, "m") )


I think think this is a valid reason. D does many things differently 
than C++. I don't know how many times I heard someone complaining about 
D's lack of struct inheritance.

-- 
/Jacob Carlborg
Mar 31 2011
prev sibling next sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 30/03/2011 20:28, Ary Manzana wrote:

 I think :: is not used in the language.

 In a recent article about D I saw:

 mixin(__traits(identifier, T) ~ " " ~
 to!string(tolower(__traits(identifier, T)[0])) ~
 __traits(identifier, T)[1..$] ~ ";");

 What if foo::bar were an alias for __traits(foo, bar) ?

 The code would look like this:

 mixin(T::identifier ~ " " ~
 to!string(tolower(T::identifier[0])) ~
 T::identifier[1..$] ~ ";");

 What do you think?

 Another uses:

 __traits(int, isArithmetic) ==> int::isArithmetic
 __traits(C, isAbstractClass) ==> C::isAbstractClass

 __traits(hasMember, S, "m") ==> S::hasMember("m")

 Well, you get the idea...

 :: might be applied to other compile time uses, but I just came up with
 this...


Hmn, interesting idea! I noticed, however, that the "foo" and "bar" in 
your example are actually swapped...

__traits(foo, bar) ==> foo::bar

should be

__traits(foo, bar) ==> bar::foo

For many the uses of __traits I can recall off the top of my head, it 
certainly seems to be both elegant and intuitive. One sore thumb would 
be __traits(compiles, ...) which I believe gets used quite frequently in 
Phobos.

Clarifications and my lack of insight into the complete breadth of 
__traits's capabilities and variations aside, I think this is the best 
suggestion for the replacement of the much maligned experimental keyword 
that I have seen posted since Don's suggestion of a magic namespace[1]. 
I'm not 100% sure if this :: syntax could also tidy up is() expressions 
too, but if it can, I can imagine it having a lot of support. If 
language design was a democracy, I'd certainly vote for it ^^

A...

[1] Search the NG for "Proposal: Replace __traits and is(typeof(XXX)) 
with a 'magic namespace'."
Mar 30 2011
parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 30/03/2011 21:09, Alix Pexton wrote:

 On 30/03/2011 20:28, Ary Manzana wrote:

 I think :: is not used in the language.

 In a recent article about D I saw:

 mixin(__traits(identifier, T) ~ " " ~
 to!string(tolower(__traits(identifier, T)[0])) ~
 __traits(identifier, T)[1..$] ~ ";");

 What if foo::bar were an alias for __traits(foo, bar) ?

 The code would look like this:

 mixin(T::identifier ~ " " ~
 to!string(tolower(T::identifier[0])) ~
 T::identifier[1..$] ~ ";");

 What do you think?

 Another uses:

 __traits(int, isArithmetic) ==> int::isArithmetic
 __traits(C, isAbstractClass) ==> C::isAbstractClass

 __traits(hasMember, S, "m") ==> S::hasMember("m")

 Well, you get the idea...

 :: might be applied to other compile time uses, but I just came up with
 this...


 Hmn, interesting idea! I noticed, however, that the "foo" and "bar" in
 your example are actually swapped...

 __traits(foo, bar) ==> foo::bar

 should be

 __traits(foo, bar) ==> bar::foo

 For many the uses of __traits I can recall off the top of my head, it
 certainly seems to be both elegant and intuitive. One sore thumb would
 be __traits(compiles, ...) which I believe gets used quite frequently in
 Phobos.

 Clarifications and my lack of insight into the complete breadth of
 __traits's capabilities and variations aside, I think this is the best
 suggestion for the replacement of the much maligned experimental keyword
 that I have seen posted since Don's suggestion of a magic namespace[1].
 I'm not 100% sure if this :: syntax could also tidy up is() expressions
 too, but if it can, I can imagine it having a lot of support. If
 language design was a democracy, I'd certainly vote for it ^^

 A...

 [1] Search the NG for "Proposal: Replace __traits and is(typeof(XXX))
 with a 'magic namespace'."


Damn I type slow ><
Mar 30 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/30/2011 09:28 PM, Ary Manzana wrote:

 I think :: is not used in the language.

 In a recent article about D I saw:

 mixin(__traits(identifier, T) ~ " " ~
 to!string(tolower(__traits(identifier, T)[0])) ~
 __traits(identifier, T)[1..$] ~ ";");

 What if foo::bar were an alias for __traits(foo, bar) ?

 The code would look like this:

 mixin(T::identifier ~ " " ~
 to!string(tolower(T::identifier[0])) ~
 T::identifier[1..$] ~ ";");

 What do you think?

 Another uses:

 __traits(int, isArithmetic) ==> int::isArithmetic
 __traits(C, isAbstractClass) ==> C::isAbstractClass

 __traits(hasMember, S, "m") ==> S::hasMember("m")

 Well, you get the idea...

 :: might be applied to other compile time uses, but I just came up with this...


Waow, this /is/ syntactic sugar ;-)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Mar 30 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 3/30/11 9:28 PM, Ary Manzana wrote:

 I think :: is not used in the language.

 In a recent article about D I saw:

 mixin(__traits(identifier, T) ~ " " ~
 to!string(tolower(__traits(identifier, T)[0])) ~
 __traits(identifier, T)[1..$] ~ ";");

 What if foo::bar were an alias for __traits(foo, bar) ?

 The code would look like this:

 mixin(T::identifier ~ " " ~
 to!string(tolower(T::identifier[0])) ~
 T::identifier[1..$] ~ ";");

 What do you think?

 Another uses:

 __traits(int, isArithmetic) ==> int::isArithmetic
 __traits(C, isAbstractClass) ==> C::isAbstractClass

 __traits(hasMember, S, "m") ==> S::hasMember("m")

 Well, you get the idea...

 :: might be applied to other compile time uses, but I just came up with
 this...


I like it.

-- 
/Jacob Carlborg
Mar 31 2011
prev sibling next sibling parent so <so so.so> writes:
On Wed, 30 Mar 2011 22:28:27 +0300, Ary Manzana <ary esperanto.org.ar>  
wrote:


 I think :: is not used in the language.

 In a recent article about D I saw:

 mixin(__traits(identifier, T) ~ " " ~
        to!string(tolower(__traits(identifier, T)[0])) ~
        __traits(identifier, T)[1..$] ~ ";");

 What if foo::bar were an alias for __traits(foo, bar) ?

 The code would look like this:

 mixin(T::identifier ~ " " ~
        to!string(tolower(T::identifier[0])) ~
        T::identifier[1..$] ~ ";");

 What do you think?

 Another uses:

 __traits(int, isArithmetic) ==> int::isArithmetic
 __traits(C, isAbstractClass) ==> C::isAbstractClass

 __traits(hasMember, S, "m") ==> S::hasMember("m")

 Well, you get the idea...

 :: might be applied to other compile time uses, but I just came up with  
 this...


I agree it is a problem (a small one) but i don't believe it deserves a  
new syntax. Especially not a major one like this.
Like many others i think "meta" is a much better choice.
Mar 31 2011
prev sibling parent reply Kagamin <spam here.lot> writes:
Ary Manzana Wrote:


 I just hate it when you have to write too much


hasMember!(S, "m")
is only 1 character longer than
S::hasMember("m")

not too much for me
Mar 31 2011
next sibling parent Ary Manzana <ary esperanto.org.ar> writes:
On 3/31/11 10:35 AM, Kagamin wrote:

 Ary Manzana Wrote:


 I just hate it when you have to write too much


 hasMember!(S, "m")
 is only 1 character longer than
 S::hasMember("m")

 not too much for me


Ah, so then I change it to:

S::hm("M")
Mar 31 2011
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-31 06:35, Kagamin wrote:

 Ary Manzana Wrote:

 I just hate it when you have to write too much


 
 hasMember!(S, "m")
 is only 1 character longer than
 S::hasMember("m")
 
 not too much for me


And hasMember!(S, "m") is actually consistent with the rest of the language 
and straight forward to read for those who know the language. 
S::hasMember("m") just adds more syntax where there's no need for it, and 
makes it so that there's that much more syntax to learn and keep straight.

- Jonathan M Davis
Mar 31 2011
parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 31/03/2011 18:37, Jonathan M Davis wrote:

 On 2011-03-31 06:35, Kagamin wrote:

 Ary Manzana Wrote:

 I just hate it when you have to write too much


 hasMember!(S, "m")
 is only 1 character longer than
 S::hasMember("m")

 not too much for me


 And hasMember!(S, "m") is actually consistent with the rest of the language
 and straight forward to read for those who know the language.
 S::hasMember("m") just adds more syntax where there's no need for it, and
 makes it so that there's that much more syntax to learn and keep straight.

 - Jonathan M Davis


I thought the :: syntax seemed pretty intuitive (keystroke savings never 
entered into my evaluation), but I seem to be in a minority on that.

After re-reading the previous discussion of __traits and its proposed 
replacement, however, I am reminded of an important point: language 
features should not have special powers that can't be replicated in 
client code.

So, with that in mind, I have to agree that using templates for things 
like hasMember has to be the way forward.

Having templates that are internal to the complier or that simply 
forward to __traits seems a bit odd to me. I think I'd rather see 
__traits simplified and more of work moved into the library, which may 
make it more versatile and easier to extend (pure speculation ^^).

Right, I'm off to go and squirrel all my uses or traits away inside 
templates, I have a sneaking suspicion that it is going to make some big 
improvements in readability ^^

A...
Apr 01 2011
parent Don <nospam nospam.com> writes:
Alix Pexton wrote:

 On 31/03/2011 18:37, Jonathan M Davis wrote:

 On 2011-03-31 06:35, Kagamin wrote:

 Ary Manzana Wrote:

 I just hate it when you have to write too much


 hasMember!(S, "m")
 is only 1 character longer than
 S::hasMember("m")

 not too much for me


 And hasMember!(S, "m") is actually consistent with the rest of the 
 language
 and straight forward to read for those who know the language.
 S::hasMember("m") just adds more syntax where there's no need for it, and
 makes it so that there's that much more syntax to learn and keep 
 straight.

 - Jonathan M Davis


 
 I thought the :: syntax seemed pretty intuitive (keystroke savings never 
 entered into my evaluation), but I seem to be in a minority on that.
 
 After re-reading the previous discussion of __traits and its proposed 
 replacement, however, I am reminded of an important point: language 
 features should not have special powers that can't be replicated in 
 client code.
 
 So, with that in mind, I have to agree that using templates for things 
 like hasMember has to be the way forward.
 
 Having templates that are internal to the complier or that simply 
 forward to __traits seems a bit odd to me. I think I'd rather see 
 __traits simplified and more of work moved into the library, which may 
 make it more versatile and easier to extend (pure speculation ^^).
 
 Right, I'm off to go and squirrel all my uses or traits away inside 
 templates, I have a sneaking suspicion that it is going to make some big 
 improvements in readability ^^
 
 A...


The chief problem is that there is no way to hide __traits(compiles).
It's just impossible. The whole idea of the meta namespace was to make 
it possible to hide the __traits.

Don't forget that an important part of that proposal was to clean up 
is(), as well.
Apr 01 2011