deprecating T(V) as c-style cast for POD T in favor of initializationsemantics - Off topic kinda

[Gianni Mariani]

So I was put straight that double(v) is the same as (double)(v)
recently and I'm somewhat surprised. I'm not the only one.

I think T(V) should have exactly the same semantics as
static_cast<T>(V) for POD T and I'm willing to bet you'll find few C++
developers that would object.

What I'd like to propose is that the c-style cast interpretation of
T(V) for POD T be the same as initialization of a temporary object T
with a value V. i.e. T id(V).

The rationale is that T(V) being a C-ctyle cast is far more dangerous
than using a c-style cast because use of T(V) in templates is often
used to initialize a temporary T and the fact that it becomes a c-
style cast in some cases and is an initialization in others would be
mostly unintended.

I do believe that most current uses of the T(V) syntax for POD T would
be in cases were the developer intended a static cast or
initialization so there would be very few cases where this would be
problematic. Deprecating the c-ctyle cast meaning should have minimal
undesired impact.

I'd like to hear how others feel about this.

[blargg]

In article
<84**********************************@e2g2000hsh.g ooglegroups.com>, Gianni
Mariani <ow*******@gmail.comwrote:

So I was put straight that double(v) is the same as (double)(v)
recently and I'm somewhat surprised. I'm not the only one.

I think T(V) should have exactly the same semantics as
static_cast<T>(V) for POD T and I'm willing to bet you'll find few C++
developers that would object.

What I'd like to propose is that the c-style cast interpretation of
T(V) for POD T be the same as initialization of a temporary object T
with a value V. i.e. T id(V).

The rationale is that T(V) being a C-ctyle cast is far more dangerous
than using a c-style cast because use of T(V) in templates is often
used to initialize a temporary T and the fact that it becomes a c-
style cast in some cases and is an initialization in others would be
mostly unintended.

I do believe that most current uses of the T(V) syntax for POD T would
be in cases were the developer intended a static cast or
initialization so there would be very few cases where this would be
problematic. Deprecating the c-ctyle cast meaning should have minimal
undesired impact.

I'd like to hear how others feel about this.

Agreed fully!

A better example is int(expr), where expr being a pointer type causes this
to be a reinterpret_cast. For example, the following code might have been
written when d is a double,

// d is a double
int i = int(d);

but later for some reason d becomes a pointer to double. At that point, it
silently becomes reinterpret_cast<int(d).

However, even if the language can't be changed, compilers could add a
warning when a functional-style cast would result in a const_cast or
reinterpret_cast. Then it becomes a quality-of-implementation issue.
Someone told me that Stroustrup had lamented that this slipped through,
and should have meant static_cast or similar all along.

[Ian Collins]

Gianni Mariani wrote:

So I was put straight that double(v) is the same as (double)(v)
recently and I'm somewhat surprised. I'm not the only one.

I think T(V) should have exactly the same semantics as
static_cast<T>(V) for POD T and I'm willing to bet you'll find few C++
developers that would object.

What I'd like to propose is that the c-style cast interpretation of
T(V) for POD T be the same as initialization of a temporary object T
with a value V. i.e. T id(V).

The rationale is that T(V) being a C-ctyle cast is far more dangerous
than using a c-style cast because use of T(V) in templates is often
used to initialize a temporary T and the fact that it becomes a c-
style cast in some cases and is an initialization in others would be
mostly unintended.

Well it certainly isn't a C style cast for pointers. You can't write

void* p;

int* n(p);

--
Ian Collins

[blargg]

In article <6m*************@mid.individual.net>, Ian Collins
<ia******@hotmail.comwrote:

Gianni Mariani wrote:

So I was put straight that double(v) is the same as (double)(v)
recently and I'm somewhat surprised. I'm not the only one.

I think T(V) should have exactly the same semantics as
static_cast<T>(V) for POD T and I'm willing to bet you'll find few C++
developers that would object.

What I'd like to propose is that the c-style cast interpretation of
T(V) for POD T be the same as initialization of a temporary object T
with a value V. i.e. T id(V).

The rationale is that T(V) being a C-ctyle cast is far more dangerous
than using a c-style cast because use of T(V) in templates is often
used to initialize a temporary T and the fact that it becomes a c-
style cast in some cases and is an initialization in others would be
mostly unintended.

Well it certainly isn't a C style cast for pointers. You can't write

void* p;

int* n(p);

But you can write (and have compile)

typedef int* ip;
void* p;
int* n = ip(p); // static_cast<int*(p)

as well as

typedef int* ip;
int i;
int* n2 = ip(i); // reinterpret_cast<int*(i)

which makes it just as unsafe as a C-style cast. The proposal is to make
these equivalent to

int* n( p ); // error
int* n2( i ); // error

or perhaps

int* n = static_cast<int*(p); // OK
int* n2 = static_cast<int*(i); // error

(I prefer the former, since a static_cast should be verbose and visible)