• "Pavel Minayev" <evilone omen.ru> Dec 22 2001
• "Walter" <walter digitalmars.com> Dec 22 2001
• "spr" <spr299.nospam ifrance.com> Dec 22 2001
• "Walter" <walter digitalmars.com> Dec 22 2001
• "Robert W. Cunningham" <rwc_2001 yahoo.com> Dec 22 2001
• "Pavel Minayev" <evilone omen.ru> Dec 22 2001
• "Walter" <walter digitalmars.com> Dec 22 2001
• "Robert W. Cunningham" <rwc_2001 yahoo.com> Dec 22 2001
• "spr" <spr299.nospam ifrance.com> Dec 22 2001
• "Pavel Minayev" <evilone omen.ru> Dec 22 2001
• "Pavel Minayev" <evilone omen.ru> Dec 22 2001

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?

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

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

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

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

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

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

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

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

"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 =)

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