www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Request: (T) == T

reply "Janice Caron" <caron800 googlemail.com> writes:
Wherever T is a type expression, please could (T) also be a type
expression, evaluating to T. That is, please could (T) be made to
compile, as if the brackets weren't there. For example, let

    (int) x;

be the same thing as

    int x;

declaring x to be an int, and let

    (int)[] p;

be the same thing as

    int[] p;

declaring p to be an array of ints. For that matter ((((T)))) should
also evaluate to T, and const(const(T)) should evaluate to const(T),
and so on.

This would be useful for generic programming, mixin strings, etc.
Dec 10 2007
next sibling parent Mael <someone somewhere.com> writes:
I support the request (T) == T,
I guess it's needed to make the langage "look" coherent,
and in particular, the difference const(T) =/= const T has always
looked weird and unusable to me, please find a
better way to formulate the subtlety !
Dec 10 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Janice Caron wrote:
 Wherever T is a type expression, please could (T) also be a type
 expression, evaluating to T. That is, please could (T) be made to
 compile, as if the brackets weren't there. For example, let
 
     (int) x;
 
 be the same thing as
 
     int x;
 
 declaring x to be an int, and let
 
     (int)[] p;
 
 be the same thing as
 
     int[] p;
 
 declaring p to be an array of ints. For that matter ((((T)))) should
 also evaluate to T, and const(const(T)) should evaluate to const(T),
 and so on.
 
 This would be useful for generic programming, mixin strings, etc.

*Channeling Walter* This may be unexpected behavior for programmers with backgrounds in other C-style languages, since (T) is a cast in those languages.
Dec 10 2007
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:fjk87l$16v0$2 digitalmars.com...
 *Channeling Walter*

 This may be unexpected behavior for programmers with backgrounds in other 
 C-style languages, since (T) is a cast in those languages.

And the D compiler, inexplicably, still parses them as such, even though it was deprecated.. what, three years ago? Flimsy excuse, either way.
Dec 10 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Janice Caron wrote:
 This would be useful for generic programming, mixin strings, etc.

Please post an example where it would be useful.
Dec 11 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Janice Caron wrote:
 On Dec 12, 2007 4:45 AM, Walter Bright <newshound1 digitalmars.com> wrote:
 Janice Caron wrote:
 This would be useful for generic programming, mixin strings, etc.


This function expects constancy to be one of "const", "invariant" or "". string newType(string constancy, string oldType) { return constancy ~ "(" ~ oldType ~ ")"; }

return constancy.length ? constancy ~ "(" ~ oldType ~ ")" : oldType;
 But I guess the real answer is aesthetics. We understand parentheses
 to imply precedence, so naturally we expect the value expression (x)
 to evaluate to x. It just seem intuitively write that the same should
 be true of type expressions, that the type expression (T) should
 evaluate to T.

I don't know any language that does this, or where the lack of it was even noticed.
 This isn't a big deal. Say no if you like; I'm not going to argue
 furiously for this one. It just seems aesthetically right.

There are so many things that need to be done, I can't see this as being needed.
Dec 12 2007
next sibling parent Roberto Mariottini <rmariottini mail.com> writes:
Walter Bright wrote:
 Janice Caron wrote:

 This isn't a big deal. Say no if you like; I'm not going to argue
 furiously for this one. It just seems aesthetically right.

There are so many things that need to be done, I can't see this as being needed.

Maybe code generators are more comfortable if const(const(T)) == const(T) and ((T)) == T. Ciao
Dec 12 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Janice Caron wrote:
 I agree. I certainly hope you will look at the thread "Constancy lost
 when compiling template mixin", and respond in some way - even if only
 to tell me I've made some obvious and stupid error - because the issue
 raised there is one that I /do/ need solving. In fact, if only I could
 get template mixins to do what I expect them to do, I wouldn't even be
 /thinking/ about constancy in string mixins at this stage.

I wouldn't worry about that right now, as the const stuff is getting revised again.
Dec 12 2007
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
Walter Bright wrote:
 Janice Caron wrote:
 This would be useful for generic programming, mixin strings, etc.

Please post an example where it would be useful.

This is just a generalization of what some of us asked for, ages ago, relative to array declarations. Only gurus know exactly what multidimensional arrays are declaring (I don't, I would have to look it up): char[2][3][4] foo; char bar[5][6][7]; But anybody could know, at a glance (well, rapidly, at least), what this is declaring: ((char[9])[10])[11] baz;
Dec 12 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On Dec 12, 2007 4:45 AM, Walter Bright <newshound1 digitalmars.com> wrote:
 Janice Caron wrote:
 This would be useful for generic programming, mixin strings, etc.

Please post an example where it would be useful.

This function expects constancy to be one of "const", "invariant" or "". string newType(string constancy, string oldType) { return constancy ~ "(" ~ oldType ~ ")"; } But I guess the real answer is aesthetics. We understand parentheses to imply precedence, so naturally we expect the value expression (x) to evaluate to x. It just seem intuitively write that the same should be true of type expressions, that the type expression (T) should evaluate to T. This isn't a big deal. Say no if you like; I'm not going to argue furiously for this one. It just seems aesthetically right.
Dec 11 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On Dec 12, 2007 8:46 AM, Walter Bright <newshound1 digitalmars.com> wrote:
 There are so many things that need to be done, I can't see this as being
 needed.

I agree. I certainly hope you will look at the thread "Constancy lost when compiling template mixin", and respond in some way - even if only to tell me I've made some obvious and stupid error - because the issue raised there is one that I /do/ need solving. In fact, if only I could get template mixins to do what I expect them to do, I wouldn't even be /thinking/ about constancy in string mixins at this stage.
Dec 12 2007
prev sibling parent Sean Kelly <sean f4.ca> writes:
Janice Caron wrote:
 Wherever T is a type expression, please could (T) also be a type
 expression, evaluating to T. That is, please could (T) be made to
 compile, as if the brackets weren't there. For example, let
 
     (int) x;
 
 be the same thing as
 
     int x;
 
 declaring x to be an int, and let
 
     (int)[] p;
 
 be the same thing as
 
     int[] p;
 
 declaring p to be an array of ints. For that matter ((((T)))) should
 also evaluate to T, and const(const(T)) should evaluate to const(T),
 and so on.
 
 This would be useful for generic programming, mixin strings, etc.

I personally think it's kind of nice to be able to distinguish between a declaration and an invalid expression without doing too much work. Though fortunately, D isn't a victim of C++'s "most vexing parse" as described by Scott Meyers, so adding this feature wouldn't be ruinous. Sean
Dec 12 2007