Any chance of our getting away from the overused round braces in casts, and adopt something less ambiguous, along the lines of the C++ casts?

It seems like a retrograde step.

> Any chance of our getting away from the overused round braces in casts,
and
> adopt something less ambiguous, along the lines of the C++ casts?
>
> It seems like a retrograde step.
>
>
>

Me I prefer function style cast... but I think that it should be the same as
for
template so that anyone could write it prefered cast as it is possible in
C++.

I would also like to have more cast as in C++ where we can explictly tell the compiler which kind of casting we want to allows. In fact, I would even like to have more cast than in C++. Some of the cast that I think of:

static_cast            // as in C++
reinterpret_cast    // low level bit reinterpret
const_cast            // as in C++ (we should add const support to D)
dynamic_cast        // base to derived

implicit_cast        // Allows if cast/conversion is implictly allowed
    without error (and disable any vendor specific warnings)

range_cast            // Ensure that the value fit in the target

same_layout_cast    // allowed if the layout is the same (x, y, z vs pt[3]
    or renamed member)

enum_cast        // Similar to range cast but only for enums

fit_cast            // fit to target range (any value lower than target
    min would be set to target min or -INF for floatting points,...)

...

and some more for plateform dependant cast, similar type cast (int to uint)
....

We should have one cast for each kind of casting that can be done... and have cast if allowed on the current plateform vs defined exactly by the language...

And I'd like to be able to add my owns...

"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:bk9ln8$21k9$1@digitaldaemon.com...
> Any chance of our getting away from the overused round braces in casts,
and
> adopt something less ambiguous, along the lines of the C++ casts?
>
> It seems like a retrograde step.
>

How about a cast property?

double d = 3.14159;
printf("%d", d.cast); // outputs 3

In article <bkaal5$2vat$1@digitaldaemon.com>, Andrew Edwards says...
>
>"Matthew Wilson" <dmd@synesis.com.au> wrote in message news:bk9ln8$21k9$1@digitaldaemon.com...
>> Any chance of our getting away from the overused round braces in casts,
>and
>> adopt something less ambiguous, along the lines of the C++ casts?
>>
>> It seems like a retrograde step.
>>
>
>How about a cast property?
>
>double d = 3.14159;
>printf("%d", d.cast); // outputs 3
>
>

Well, you'd still need to tell it what to cast to wouldn't you?:
d.cast(int)
so what's the difference?

And it would be better to have:
d.toString(formatstring)
d.toInt
d.toUInt
etc. and all the baggage that follows.

John Boucher
The King had Humpty pushed.

"John Boucher" <John_member@pathlink.com> wrote in message news:bkacc2$ar$1@digitaldaemon.com...
>
> Well, you'd still need to tell it what to cast to wouldn't you?:
> d.cast(int)
> so what's the difference?
>
not necessarily!

format specifiers provides the format of the intended input (in this case int). Upon seeing the cast property, printf should automatically convert d.cast to the expected input.

likewise,

char [] dstr;
char[30] cstr = "Is this even possible?";
dstr = cstr; // error
dstr = cstr.cast; // ok

the compiler already knows what's expected and will automatally bark at improperly typed inputs or rvalues. Upon seeing cstr.cast however, it should treat cstr as if it were a dynamic string.

Andrew

"Philippe Mori" <philippe_mori@hotmail.com> escreveu na mensagem news:bk9q8l$27ov$1@digitaldaemon.com...
>
> > Any chance of our getting away from the overused round braces in casts,
> and
> > adopt something less ambiguous, along the lines of the C++ casts?
> >
> > It seems like a retrograde step.
> >
> >
> >
>
> Me I prefer function style cast... but I think that it should be the same
as
> for
> template so that anyone could write it prefered cast as it is possible in
> C++.
>
> I would also like to have more cast as in C++ where we can explictly tell the compiler which kind of casting we want to allows. In fact, I would
even
> like to have more cast than in C++. Some of the cast that I think of:
>
> static_cast            // as in C++
> reinterpret_cast    // low level bit reinterpret
> const_cast            // as in C++ (we should add const support to D)
> dynamic_cast        // base to derived
>
> implicit_cast        // Allows if cast/conversion is implictly allowed
>     without error (and disable any vendor specific warnings)
>
> range_cast            // Ensure that the value fit in the target
>
> same_layout_cast    // allowed if the layout is the same (x, y, z vs pt[3]
>     or renamed member)
>
> enum_cast        // Similar to range cast but only for enums
>
> fit_cast            // fit to target range (any value lower than target
>     min would be set to target min or -INF for floatting points,...)
>
> ...
>
> and some more for plateform dependant cast, similar type cast (int to
uint)
> ....
>
> We should have one cast for each kind of casting that can be done... and have cast if allowed on the current plateform vs defined exactly by the language...
>
> And I'd like to be able to add my owns...

IMO we should just keep the simple cast (using a "cast(type, value)" syntax to reduce the parameters) and have all the other casts as templates. If we do it this way we can keep the language clean of one hundred and one new keywords and the syntax of templates will certainly improve (just imagine dozens of developers frustrated with explicit instantiantion ;). Also templates are the standard way to provide generic code (i.e. you would be able to add your owns).



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003

This gets my vote.  Keep the (cast) I vote.

One thing that does worry me, is that there are now a ton of keywords in D, I realize that there all needed, but what are everyone elses thoughts on this ?  Id like to keep it to as little as possible.

Charles
"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message
news:bkaqnn$lbt$1@digitaldaemon.com...
> "Philippe Mori" <philippe_mori@hotmail.com> escreveu na mensagem news:bk9q8l$27ov$1@digitaldaemon.com...
> >
> > > Any chance of our getting away from the overused round braces in
casts,
> > and
> > > adopt something less ambiguous, along the lines of the C++ casts?
> > >
> > > It seems like a retrograde step.
> > >
> > >
> > >
> >
> > Me I prefer function style cast... but I think that it should be the
same
> as
> > for
> > template so that anyone could write it prefered cast as it is possible
in
> > C++.
> >
> > I would also like to have more cast as in C++ where we can explictly
tell
> > the compiler which kind of casting we want to allows. In fact, I would
> even
> > like to have more cast than in C++. Some of the cast that I think of:
> >
> > static_cast            // as in C++
> > reinterpret_cast    // low level bit reinterpret
> > const_cast            // as in C++ (we should add const support to D)
> > dynamic_cast        // base to derived
> >
> > implicit_cast        // Allows if cast/conversion is implictly allowed
> >     without error (and disable any vendor specific warnings)
> >
> > range_cast            // Ensure that the value fit in the target
> >
> > same_layout_cast    // allowed if the layout is the same (x, y, z vs
pt[3]
> >     or renamed member)
> >
> > enum_cast        // Similar to range cast but only for enums
> >
> > fit_cast            // fit to target range (any value lower than target
> >     min would be set to target min or -INF for floatting points,...)
> >
> > ...
> >
> > and some more for plateform dependant cast, similar type cast (int to
> uint)
> > ....
> >
> > We should have one cast for each kind of casting that can be done... and have cast if allowed on the current plateform vs defined exactly by the language...
> >
> > And I'd like to be able to add my owns...
>
> IMO we should just keep the simple cast (using a "cast(type, value)"
syntax
> to reduce the parameters) and have all the other casts as templates. If we do it this way we can keep the language clean of one hundred and one new keywords and the syntax of templates will certainly improve (just imagine dozens of developers frustrated with explicit instantiantion ;). Also templates are the standard way to provide generic code (i.e. you would be able to add your owns).
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
>
>

What about smthng like "variable.doCast(newType)" (standard method call). Yes,
will be more difficult for expressions, but not always:

(variable1+variable2/variable4).doCast(newType)

Me, one, I would preffer this to (newType) (Variable1+Variable2);
It is really necessar to have an operator-based syntax?


Also, other casts should be easier to add.

Yes, and please drop the "_" in function names. Just an innocent idea.



In article <bkav5t$rdo$1@digitaldaemon.com>, Charles Sanders says...
>
>This gets my vote.  Keep the (cast) I vote.
>
>One thing that does worry me, is that there are now a ton of keywords in D, I realize that there all needed, but what are everyone elses thoughts on this ?  Id like to keep it to as little as possible.
>
>Charles
>"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message
>news:bkaqnn$lbt$1@digitaldaemon.com...
>> "Philippe Mori" <philippe_mori@hotmail.com> escreveu na mensagem news:bk9q8l$27ov$1@digitaldaemon.com...
>> >
>> > > Any chance of our getting away from the overused round braces in
>casts,
>> > and
>> > > adopt something less ambiguous, along the lines of the C++ casts?
>> > >
>> > > It seems like a retrograde step.
>> > >
>> > >
>> > >
>> >
>> > Me I prefer function style cast... but I think that it should be the
>same
>> as
>> > for
>> > template so that anyone could write it prefered cast as it is possible
>in
>> > C++.
>> >
>> > I would also like to have more cast as in C++ where we can explictly
>tell
>> > the compiler which kind of casting we want to allows. In fact, I would
>> even
>> > like to have more cast than in C++. Some of the cast that I think of:
>> >
>> > static_cast            // as in C++
>> > reinterpret_cast    // low level bit reinterpret
>> > const_cast            // as in C++ (we should add const support to D)
>> > dynamic_cast        // base to derived
>> >
>> > implicit_cast        // Allows if cast/conversion is implictly allowed
>> >     without error (and disable any vendor specific warnings)
>> >
>> > range_cast            // Ensure that the value fit in the target
>> >
>> > same_layout_cast    // allowed if the layout is the same (x, y, z vs
>pt[3]
>> >     or renamed member)
>> >
>> > enum_cast        // Similar to range cast but only for enums
>> >
>> > fit_cast            // fit to target range (any value lower than target
>> >     min would be set to target min or -INF for floatting points,...)
>> >
>> > ...
>> >
>> > and some more for plateform dependant cast, similar type cast (int to
>> uint)
>> > ....
>> >
>> > We should have one cast for each kind of casting that can be done... and have cast if allowed on the current plateform vs defined exactly by the language...
>> >
>> > And I'd like to be able to add my owns...
>>
>> IMO we should just keep the simple cast (using a "cast(type, value)"
>syntax
>> to reduce the parameters) and have all the other casts as templates. If we do it this way we can keep the language clean of one hundred and one new keywords and the syntax of templates will certainly improve (just imagine dozens of developers frustrated with explicit instantiantion ;). Also templates are the standard way to provide generic code (i.e. you would be able to add your owns).
>>
>>
>>
>> ---
>> Outgoing mail is certified Virus Free.
>> Checked by AVG anti-virus system (http://www.grisoft.com).
>> Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
>>
>>
>
>

And this approach will be easier to manage in the "intellisense" (code
completion) based editors...


In article <bkbe0c$1gsc$1@digitaldaemon.com>, Felix says...
>
>What about smthng like "variable.doCast(newType)" (standard method call). Yes,
>will be more difficult for expressions, but not always:
>
>(variable1+variable2/variable4).doCast(newType)
>
>Me, one, I would preffer this to (newType) (Variable1+Variable2);
>It is really necessar to have an operator-based syntax?
>
>
>Also, other casts should be easier to add.
>
>Yes, and please drop the "_" in function names. Just an innocent idea.
>
>
>
>In article <bkav5t$rdo$1@digitaldaemon.com>, Charles Sanders says...
>>
>>This gets my vote.  Keep the (cast) I vote.
>>
>>One thing that does worry me, is that there are now a ton of keywords in D, I realize that there all needed, but what are everyone elses thoughts on this ?  Id like to keep it to as little as possible.
>>
>>Charles
>>"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message
>>news:bkaqnn$lbt$1@digitaldaemon.com...
>>> "Philippe Mori" <philippe_mori@hotmail.com> escreveu na mensagem news:bk9q8l$27ov$1@digitaldaemon.com...
>>> >
>>> > > Any chance of our getting away from the overused round braces in
>>casts,
>>> > and
>>> > > adopt something less ambiguous, along the lines of the C++ casts?
>>> > >
>>> > > It seems like a retrograde step.
>>> > >
>>> > >
>>> > >
>>> >
>>> > Me I prefer function style cast... but I think that it should be the
>>same
>>> as
>>> > for
>>> > template so that anyone could write it prefered cast as it is possible
>>in
>>> > C++.
>>> >
>>> > I would also like to have more cast as in C++ where we can explictly
>>tell
>>> > the compiler which kind of casting we want to allows. In fact, I would
>>> even
>>> > like to have more cast than in C++. Some of the cast that I think of:
>>> >
>>> > static_cast            // as in C++
>>> > reinterpret_cast    // low level bit reinterpret
>>> > const_cast            // as in C++ (we should add const support to D)
>>> > dynamic_cast        // base to derived
>>> >
>>> > implicit_cast        // Allows if cast/conversion is implictly allowed
>>> >     without error (and disable any vendor specific warnings)
>>> >
>>> > range_cast            // Ensure that the value fit in the target
>>> >
>>> > same_layout_cast    // allowed if the layout is the same (x, y, z vs
>>pt[3]
>>> >     or renamed member)
>>> >
>>> > enum_cast        // Similar to range cast but only for enums
>>> >
>>> > fit_cast            // fit to target range (any value lower than target
>>> >     min would be set to target min or -INF for floatting points,...)
>>> >
>>> > ...
>>> >
>>> > and some more for plateform dependant cast, similar type cast (int to
>>> uint)
>>> > ....
>>> >
>>> > We should have one cast for each kind of casting that can be done... and have cast if allowed on the current plateform vs defined exactly by the language...
>>> >
>>> > And I'd like to be able to add my owns...
>>>
>>> IMO we should just keep the simple cast (using a "cast(type, value)"
>>syntax
>>> to reduce the parameters) and have all the other casts as templates. If we do it this way we can keep the language clean of one hundred and one new keywords and the syntax of templates will certainly improve (just imagine dozens of developers frustrated with explicit instantiantion ;). Also templates are the standard way to provide generic code (i.e. you would be able to add your owns).
>>>
>>>
>>>
>>> ---
>>> Outgoing mail is certified Virus Free.
>>> Checked by AVG anti-virus system (http://www.grisoft.com).
>>> Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
>>>
>>>
>>
>>
>
>

> format specifiers provides the format of the intended input (in this case int). Upon seeing the cast property, printf should automatically convert d.cast to the expected input.

Automatic casting won't works with printf since the format string may not be known to the compiler... and the compiler assumes that the type is correct!

>
> likewise,
>
> char [] dstr;
> char[30] cstr = "Is this even possible?";
> dstr = cstr; // error
> dstr = cstr.cast; // ok
>
> the compiler already knows what's expected and will automatally bark at improperly typed inputs or rvalues. Upon seeing cstr.cast however, it
should
> treat cstr as if it were a dynamic string.
>

For conversion, I do like the idea... And it would allows conversion that are normally explicit to be done implictly... So something like that should even be possible:

int i;
bool b = (1 + i).cast;

double d;
int j = (3.453 * d).cast;
int k = d.cast;

uint m;
if (m == j.cast)    // convert j to unsigned for comparison
{
}