May 06, 2004
Walter wrote:
> I should also confess that I'm looking into implementing things like:
> 
>     a = (int == T) ? c : d;    // is T an alias for type int?
> 
> which will cause even more parser grief disambiguating them from C style
> casts. Essentially, I'm looking at the possibility of a type being an
> expression. The utility of it is to be able to write simpler and more
> straightforward generic code, without resorting to forests of inscrutable
> template specializations.

So does that means we could store a type in a variable! That's the solution to the var_args problem.

-- 
Julio César Carrascal Urquijo
http://jcesar.f2o.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
O---@ M V? PS+ PE Y+ PGP t+ 5- X+++@ R- tv+(++) b++> DI!
D++> G e+> h-- r- y+
------END GEEK CODE BLOCK------
May 06, 2004
Walter wrote:
> I should also confess that I'm looking into implementing things like:
> 
>     a = (int == T) ? c : d;    // is T an alias for type int?
> 
> which will cause even more parser grief disambiguating them from C style
> casts. Essentially, I'm looking at the possibility of a type being an
> expression. The utility of it is to be able to write simpler and more
> straightforward generic code, without resorting to forests of inscrutable
> template specializations.

Hey... I remember talking about something along these lines some time ago.  Hope to see it happen.  This combined with the 'variant' type proposed elsewhere on the NG would make for one fine system, methinks.

-C. Sauls
-Invironz
May 06, 2004
On Wed, 5 May 2004 10:04:08 -0700, "Walter" <newshound@digitalmars.com> wrote:

>Currently, D supports C style casts:
>
>    (type)expression
>
>as well as D style casts:
>
>    cast(type)expression
>
>The C style casts are tricky to parse right, and I think will cause increasing problems down the road due to the syntactical ambiguities with it. The D style cast has no such problems, and it has the advantage of being greppable (as some programming styles consider an explicit cast to be a bug, and being able to find and check them all to be a Good Thing).
>
>What do people think about first deprecating, then removing, the C style cast?
>

do it ... and finally resolve that persistant BUG

int main( char[][] args ) {
	int a;
	int b
	a = args.length;
	b = (a);

	return 0;
}
//casttest.d(7): semicolon expected, not 'a'


May 09, 2004
Walter wrote:
 > I should also confess that I'm looking into implementing things like:
> 
>     a = (int == T) ? c : d;    // is T an alias for type int?
> 
> which will cause even more parser grief disambiguating them from C style
> casts. Essentially, I'm looking at the possibility of a type being an
> expression. The utility of it is to be able to write simpler and more
> straightforward generic code, without resorting to forests of inscrutable
> template specializations.

I like this! But why not use the same method to avoid the ambiguity as for cast?

a= (type(int) == type(T)) ? c : d;

or (maybe better)

a= int.type == T.type ? c : d;

or perhaps

a= T.typeEquals(int) ? c : d;

or something like that?


Hauke
May 11, 2004
"Hauke Duden" <H.NS.Duden@gmx.net> wrote in message news:c7l3qr$1i5n$1@digitaldaemon.com...
> Walter wrote:
>   > I should also confess that I'm looking into implementing things like:
> >
> >     a = (int == T) ? c : d;    // is T an alias for type int?
> >
> > which will cause even more parser grief disambiguating them from C style casts. Essentially, I'm looking at the possibility of a type being an expression. The utility of it is to be able to write simpler and more straightforward generic code, without resorting to forests of
inscrutable
> > template specializations.
>
> I like this! But why not use the same method to avoid the ambiguity as for cast?
>
> a= (type(int) == type(T)) ? c : d;

Something like that will have to be done. For example, is:

    foo*fp[]

an expression or a type? It's ambiguous. There'll have to be something like what you propose. Probably 'typename' instead of 'type', as 'type' appears too often as a variable name.

> or (maybe better)
> a= int.type == T.type ? c : d;

Parsing ambiguity problems.

> or perhaps
> a= T.typeEquals(int) ? c : d;
>
> or something like that?

I think typename(int) will parse easilly and so will work best.


May 11, 2004
Could this fall into the domain of typeof() perhaps?  That's already in the language, and likely to be a common companion to whatever becomes this.  Or at least that's what I see.

a = typeof(int) == typeof(T) ? c : d;

-C. Sauls
-Invironz

Walter wrote:
> "Hauke Duden" <H.NS.Duden@gmx.net> wrote in message
> news:c7l3qr$1i5n$1@digitaldaemon.com...
> 
>>Walter wrote:
>>  > I should also confess that I'm looking into implementing things like:
>>
>>>    a = (int == T) ? c : d;    // is T an alias for type int?
>>>
>>>which will cause even more parser grief disambiguating them from C style
>>>casts. Essentially, I'm looking at the possibility of a type being an
>>>expression. The utility of it is to be able to write simpler and more
>>>straightforward generic code, without resorting to forests of
> 
> inscrutable
> 
>>>template specializations.
>>
>>I like this! But why not use the same method to avoid the ambiguity as
>>for cast?
>>
>>a= (type(int) == type(T)) ? c : d;
> 
> 
> Something like that will have to be done. For example, is:
> 
>     foo*fp[]
> 
> an expression or a type? It's ambiguous. There'll have to be something like
> what you propose. Probably 'typename' instead of 'type', as 'type' appears
> too often as a variable name.
> 
> 
>>or (maybe better)
>>a= int.type == T.type ? c : d;
> 
> 
> Parsing ambiguity problems.
> 
> 
>>or perhaps
>>a= T.typeEquals(int) ? c : d;
>>
>>or something like that?
> 
> 
> I think typename(int) will parse easilly and so will work best.
> 
> 
May 16, 2004
C-style cast is informally deprecated even in C++, where you should use template-like casts static_cast, dynamic_cast and reinterpret_cast, to which D cast is similar enough.

Having said that, D has a few other points where C programmers may stumble, and many many points left from C where non-C programmers will. This cannot be changed. And the differences from C are largely of semantical and not syntactical nature, and may cause some headache at first but prove very advantageous later on.

Having also seen that some otherwise legal expressions get rejected because they "look like" a C-style cast, but in fact aren't, makes me vote to remove C-style casts.

Now, it's already happened. And is one more word "cast" that much of a problem?

-eye

Chr. Grade schrieb:
> 
> The closer D will remain related to C and Cpp, the more likely people are willing to have a closer look at D and programm with it and switch to it. D has to be intuitive for D-newbies. I merely tried D because it looked and felt so familiar.
> I'd be more than disencouraged if C/Cpp style casts were missing, because I'm simply used to them; I like them.
May 18, 2004
Won't work as an argument to typeof, because
    typeof(foo[])
is ambiguous.


May 18, 2004
In DMD 0.89, the following:

    int so = (schar*)slice - (schar*)string;

The compiler suggests:

   "C style cast deprecated, use cast(*schar)(slice)"

That doesn't work, but the following does:

    int so = cast(schar*)slice - cast(schar*)string;

Any danger in ignoring the compiler here?  Should the compiler give a better message?

BTW, this is Vathix's string.d

BA

May 24, 2004
"Brad Anderson" <brad@sankaty.dot.com> wrote in message news:c8bsf6$1rvi$1@digitaldaemon.com...
> In DMD 0.89, the following:
>
>      int so = (schar*)slice - (schar*)string;
>
> The compiler suggests:
>
>     "C style cast deprecated, use cast(*schar)(slice)"
>
> That doesn't work, but the following does:
>
>      int so = cast(schar*)slice - cast(schar*)string;
>
> Any danger in ignoring the compiler here?  Should the compiler give a
better
> message?

No. Yes. <g>


1 2 3 4 5
Next ›   Last »