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

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

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

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