www.digitalmars.com         C & C++   DMDScript  

D - cast syntax

reply "Pavel Minayev" <evilone omen.ru> writes:
At first I liked it, now after I've used it a bit I must
say it's not so good... definitely better than old C-style
but still, when I look at (my own!) code with cast(), it's
quite hard to tell what's being casted, quickly. It just
doesn't "look right", so to say...

My suggestions would be either as() method or "as" operator:

    hFile = null as HANDLE;
    hFile = null.as(HANDLE);

What do you think?
Dec 22 2001
parent reply "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a01gdf$2md3$1 digitaldaemon.com...
 At first I liked it, now after I've used it a bit I must
 say it's not so good... definitely better than old C-style
 but still, when I look at (my own!) code with cast(), it's
 quite hard to tell what's being casted, quickly. It just
 doesn't "look right", so to say...

 My suggestions would be either as() method or "as" operator:

     hFile = null as HANDLE;
     hFile = null.as(HANDLE);

 What do you think?
Hmm, still doesn't look right. Perhaps: cast<type> expression At least in this instance, the < and > aren't lexically ambiguous.
Dec 22 2001
next sibling parent reply "spr" <spr299.nospam ifrance.com> writes:
"Walter" <walter digitalmars.com> a écrit dans le message de news:
a02ebc$ajb$2 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a01gdf$2md3$1 digitaldaemon.com...
 At first I liked it, now after I've used it a bit I must
 say it's not so good... definitely better than old C-style
 but still, when I look at (my own!) code with cast(), it's
 quite hard to tell what's being casted, quickly. It just
 doesn't "look right", so to say...

 My suggestions would be either as() method or "as" operator:

     hFile = null as HANDLE;
     hFile = null.as(HANDLE);

 What do you think?
Hmm, still doesn't look right. Perhaps: cast<type> expression At least in this instance, the < and > aren't lexically ambiguous.
what about: cast (expression, type) this way, you can't miss what is being casted ;-)
Dec 22 2001
parent reply "Walter" <walter digitalmars.com> writes:
"spr" <spr299.nospam ifrance.com> wrote in message
news:a02gue$ckb$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> a écrit dans le message de news:
 a02ebc$ajb$2 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a01gdf$2md3$1 digitaldaemon.com...
 At first I liked it, now after I've used it a bit I must
 say it's not so good... definitely better than old C-style
 but still, when I look at (my own!) code with cast(), it's
 quite hard to tell what's being casted, quickly. It just
 doesn't "look right", so to say...

 My suggestions would be either as() method or "as" operator:

     hFile = null as HANDLE;
     hFile = null.as(HANDLE);

 What do you think?
Hmm, still doesn't look right. Perhaps: cast<type> expression At least in this instance, the < and > aren't lexically ambiguous.
what about: cast (expression, type) this way, you can't miss what is being casted ;-)
That will syntactically work, too.
Dec 22 2001
next sibling parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Walter wrote:

 "spr" <spr299.nospam ifrance.com> wrote in message
 news:a02gue$ckb$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> a écrit dans le message de news:
 a02ebc$ajb$2 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a01gdf$2md3$1 digitaldaemon.com...
 At first I liked it, now after I've used it a bit I must
 say it's not so good... definitely better than old C-style
 but still, when I look at (my own!) code with cast(), it's
 quite hard to tell what's being casted, quickly. It just
 doesn't "look right", so to say...

 My suggestions would be either as() method or "as" operator:

     hFile = null as HANDLE;
     hFile = null.as(HANDLE);

 What do you think?
Hmm, still doesn't look right. Perhaps: cast<type> expression At least in this instance, the < and > aren't lexically ambiguous.
what about: cast (expression, type) this way, you can't miss what is being casted ;-)
That will syntactically work, too.
I know it has been long, long ago in a thread far, far away, but I still like the "functional" form of casting: int i = 30; float j = float(i); And to toss in $0.02 on typeless consts: Get rid of them! The above form of casting can also be used declaratively with constants: const i = float(30). // i is a float, despite the fact that "30" does "look" like an int. It is all syntactic sugar, but I hate to see untyped declarations... An explicit type should always be required, even when it "seems" implicit in the notation of the manifest constant. Notation is just too weak: The addition of a single, practically invisible, period (something also mentioned in prior treads concerning dereference notation) can change everything: const i = 30; const j = 30.; Please disallow it! -BobC
Dec 22 2001
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C24E40C.7FEF7E02 yahoo.com...

 It is all syntactic sugar, but I hate to see untyped declarations...  An
 explicit type should always be required, even when it "seems" implicit in
 the notation of the manifest constant.  Notation is just too weak:  The
 addition of a single, practically invisible, period (something also
 mentioned in prior treads concerning dereference notation) can change
 everything:

 const i = 30;
 const j = 30.;

 Please disallow it!
I would agree with you, but there is one thing that made me request such a feature. There's lots of legacy C (and even C++!) headers around, starting from Windows API itself, that use #define to declare constant - which can be thought as "untyped const" partially. Making D support such things, maybe with some special syntax, would aid greatly in porting such headers. Practically, that'd help really much with the same WinAPI. As for the syntax... what about extern? extern(C) const WM_CLOSE = 0x0010; // okay const WM_QUIT = 0x0012; // compile error This is especially fine if we remember that C allows to omit typename in const (assuming it is int, though). On other hand, this way you will NEVER occasionally forget to mention the type and get something wrong as the cases you've mentioned (const j = 30.;).
Dec 22 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
news:3C24E40C.7FEF7E02 yahoo.com...
 I know it has been long, long ago in a thread far, far away, but I still
 like the "functional" form of casting:

 int i = 30;
 float j = float(i);
The trouble with the functional form is, suppose you want to cast to foo*: foo*(i) It doesn't work in the general case, so an alternate form must be there anyway.
 And to toss in $0.02 on typeless consts:  Get rid of them
They aren't there <g>.
Dec 22 2001
parent "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
Walter wrote:

 "Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message
 news:3C24E40C.7FEF7E02 yahoo.com...
 I know it has been long, long ago in a thread far, far away, but I still
 like the "functional" form of casting:

 int i = 30;
 float j = float(i);
The trouble with the functional form is, suppose you want to cast to foo*: foo*(i) It doesn't work in the general case, so an alternate form must be there anyway.
Personally, my style would be to create a typedef, then cast using that. Of course, that could become cumbersome, when lots of pointers to lots of types are used, but then again, perhaps a little hassle is a good thing in such situations. IMHO, the real problem is the syntax related to "*": That's what needs fixing in a way that will allow casting to be clarified and de-uglified. (Of course, the language idealists would eliminate the problem simply by outlawing casting. So they'd say all solutions to the casting problem would, by definition, be ugly. They'd probably get rid of pointers too.) We should be able to shove the asterisk inside the parens without loss of clarity: foo(*i); Then this small voice in my head said: "OK smarty-pants, what about casting foo to be a pointer to a function that returns a pointer to a function returning an array of ints?" This is a situation where placing one's fingers in one's ears only makes the small voice louder. Time for bed. -BobC
Dec 22 2001
prev sibling parent reply "spr" <spr299.nospam ifrance.com> writes:
"Walter" <walter digitalmars.com> wrote: a02ii9$dlj$2 digitaldaemon.com...
 "spr" <spr299.nospam ifrance.com> wrote in message
 news:a02gue$ckb$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> a écrit dans le message de news:
 a02ebc$ajb$2 digitaldaemon.com...
 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a01gdf$2md3$1 digitaldaemon.com...
     hFile = null as HANDLE;
     hFile = null.as(HANDLE);
     cast<type> expression
 cast (expression, type)
another suggestion... if D is going to feature templates, maybe you could go the C++ way after all: cast<type>(expression) and cast() would look like a template function: // C++ code template<typename destT, typename srcT> cast(srcT expression) { return (destT)expression; } (i'm pretty new here, so i don't know if all this has already been debated before)
Dec 22 2001
parent "Pavel Minayev" <evilone omen.ru> writes:
"spr" <spr299.nospam ifrance.com> wrote in message
news:a02o8j$gkg$1 digitaldaemon.com...

 another suggestion...
 if D is going to feature templates, maybe you could go the C++ way after
 all:

 cast<type>(expression)

 and cast() would look like a template function:

 // C++ code
 template<typename destT, typename srcT>
 cast(srcT expression) { return (destT)expression; }

 (i'm pretty new here, so i don't know if all this has already been debated
 before)
It looks like C++ cast syntax, which I - personally - never liked. In fact, angled brackets just seem ugly to me. Let it be something more simple and elegant =)
Dec 22 2001
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:a02ebc$ajb$2 digitaldaemon.com...

 Hmm, still doesn't look right. Perhaps:

     cast<type> expression

 At least in this instance, the < and > aren't lexically ambiguous.
It's almost the same as now...
Dec 22 2001