D - cast syntax
- Pavel Minayev (9/9) Dec 22 2001 At first I liked it, now after I've used it a bit I must
- Walter (5/14) Dec 22 2001 Hmm, still doesn't look right. Perhaps:
- spr (5/22) Dec 22 2001 what about:
- Walter (3/29) Dec 22 2001 That will syntactically work, too.
- Robert W. Cunningham (19/52) Dec 22 2001 I know it has been long, long ago in a thread far, far away, but I still
- Pavel Minayev (18/27) Dec 22 2001 I would agree with you, but there is one thing that made
- Walter (7/12) Dec 22 2001 The trouble with the functional form is, suppose you want to cast to foo...
- Robert W. Cunningham (20/31) Dec 22 2001 Personally, my style would be to create a typedef, then cast using that....
- spr (11/22) Dec 22 2001 another suggestion...
- Pavel Minayev (5/15) Dec 22 2001 It looks like C++ cast syntax, which I - personally - never liked.
- Pavel Minayev (3/6) Dec 22 2001 It's almost the same as now...
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
"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
"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...what about: cast (expression, type) this way, you can't miss what is being casted ;-)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
"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...That will syntactically work, too."Pavel Minayev" <evilone omen.ru> wrote in message news:a01gdf$2md3$1 digitaldaemon.com...what about: cast (expression, type) this way, you can't miss what is being casted ;-)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
Walter wrote:"spr" <spr299.nospam ifrance.com> wrote in message news:a02gue$ckb$1 digitaldaemon.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); 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"Walter" <walter digitalmars.com> a écrit dans le message de news: a02ebc$ajb$2 digitaldaemon.com...That will syntactically work, too."Pavel Minayev" <evilone omen.ru> wrote in message news:a01gdf$2md3$1 digitaldaemon.com...what about: cast (expression, type) this way, you can't miss what is being casted ;-)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
"Pavel Minayev" <evilone omen.ru> "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
"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 themThey aren't there <g>.
Dec 22 2001
Walter wrote:"Robert W. Cunningham" <rwc_2001 yahoo.com> wrote in message news:3C24E40C.7FEF7E02 yahoo.com...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. -BobCI 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.
Dec 22 2001
"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> expressionanother 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)cast (expression, type)
Dec 22 2001
"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
"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