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 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
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 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 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
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 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 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 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 Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
How about not inventing new syntaxes? Leave that to C++7xFF.
Mar 30 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 next 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 "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
prev sibling parent "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
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 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