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 "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
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.


 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 ~ ")";
     }


	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 reply "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
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 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