Corrected: Proposal: Increasing type safety with a keyword

I

Ioannis Vranos

Proposal:

We can increase type safety in C++ by adding a single keyword. The current proposal uses the keyword "only".


Example 1:

only int x= 4;

x= 5; // Ok

x= 5.0; // Error

x= 5U // Error



Example 2:

int i= 5;

only unsigned x= 4U;

x= 5; // Error

x= 5LU; // Error

x= i; // Error



Example 3:

only float f= 4.0F;

f= 4; // Error

f= 5.0; // Error

f= 4.0F; // OK




// It accepts any built in type
void somefunc(const int &x);


// It accepts only an int and a const int object
void somefunc(only const int &x);




It is simple like that, and the concept is backwards compatible.




What do you think?
 
V

Victor Bazarov

Ioannis said:
Proposal:

We can increase type safety in C++ by adding a single keyword. The
current proposal uses the keyword "only".


Example 1:

only int x= 4;

x= 5; // Ok

x= 5.0; // Error

x= 5U // Error



Example 2:

int i= 5;

only unsigned x= 4U;

x= 5; // Error

x= 5LU; // Error

x= i; // Error



Example 3:

only float f= 4.0F;

f= 4; // Error

f= 5.0; // Error

f= 4.0F; // OK




// It accepts any built in type
void somefunc(const int &x);


// It accepts only an int and a const int object
void somefunc(only const int &x);




It is simple like that, and the concept is backwards compatible.




What do you think?

I think I don't have a clear understanding of what problem this solves.

V
 
V

Vladyslav Lazarenko

Proposal:

We can increase type safety in C++ by adding a single keyword. The current proposal uses the keyword "only".

Example 1:

only int x= 4;

x= 5;  // Ok

x= 5.0; // Error

x= 5U // Error

Example 2:

int i= 5;

only unsigned x= 4U;

x= 5; // Error

x= 5LU; // Error

x= i; // Error

Example 3:

only float f= 4.0F;

f= 4; // Error

f= 5.0; // Error

f= 4.0F; // OK

Up to here you can use "const" keyword to let the compiler know that
value is constant or use compile-time constant expression which is
even better.
// It accepts any built in type
void somefunc(const int &x);

// It accepts only an int and a const int object
void somefunc(only const int &x);

Both functions in your example accepts constant reference to object of
type "int" and I don't see what difference the "only" keyword makes.
So what is the point?
 
I

Ioannis Vranos

Victor said:
I think I don't have a clear understanding of what problem this solves.


Type safety, more specifically, avoiding implicit type conversions.
 
I

Ioannis Vranos

Vladyslav said:
>

Both functions in your example accepts constant reference to object of
type "int" and I don't see what difference the "only" keyword makes.
So what is the point?


The point of the proposal is that in the first case:


// It accepts any built in type
void somefunc(const int &x);



We can do:


somefunc(45.76);



while in the second case:


// It accepts only an int and a const int object
void somefunc(only const int &x);


somefunc(45.76);

would be a compiler error.
 
V

Victor Bazarov

Ioannis said:
Type safety, more specifically, avoiding implicit type conversions.

That's not a problem. That's a solution. What's the problem with those?

V
 
A

Alf P. Steinbach

* Ioannis Vranos:
Proposal:

We can increase type safety in C++ by adding a single keyword. The
current proposal uses the keyword "only".


Example 1:
only int x= 4;

x= 5; // Ok
x= 5.0; // Error
x= 5U // Error

Example 2:
int i= 5;

only unsigned x= 4U;
x= 5; // Error
x= 5LU; // Error
x= i; // Error

Example 3:
only float f= 4.0F;

f= 4; // Error
f= 5.0; // Error
f= 4.0F; // OK

// It accepts any built in type
void somefunc(const int &x);

// It accepts only an int and a const int object
void somefunc(only const int &x);

It is simple like that, and the concept is backwards compatible.

What do you think?

As I recall someone proposed a similar class template a while back.

But even if nobody did, I do that now, so, it's done:

template< typename T >
class Only
{
private:
T myValue;

template< typename U > Only( U v ); // No constr. from other types.

public:
// STATIC_ASSERT( that T is built-in type or something like that )
Only( T v ): myValue( v ) {}

T value() const { return myValue; }
operator T () const { return value(); }
};

Disclaimer: above code is off-the-cuff, not fondled by any dirty compiler.

Hm, thinking of it I have actually proposed something very similar earlier, many
years ago, namely, for the purpose of ensuring 'bool' conditional expressions in
novice code.

However, that proposal was shot down by (1) others' ideas about how unsuitable
this was for novices, and (2) actually trying it, which showed that the
standard's formal UB for redefining a keyword when using standard library
headers, is not just formal UB but, with at least one compiler, very real...


Cheers,

- Alf
 
V

Vladyslav Lazarenko

Vladyslav Lazarenko wrote:

 >



The point of the proposal is that in the first case:

// It accepts any built in type
void somefunc(const int &x);

We can do:

somefunc(45.76);

while in the second case:

// It accepts only an int and a const int object
void somefunc(only const int &x);

somefunc(45.76);

would be a compiler error.

What is the problem with that code? Implicit conversion in that case
is acceptable. In C++ and many other languages this is done to take
advantages of type hierarchies and I don't see any problems with that.
The only problem you may face is unfavorable implicit conversions of
high-level classes, but C++ has "explicit" keyword to prevent that.
 
V

Vaclav Haisman

Ioannis Vranos wrote, On 30.3.2009 22:04:
Proposal:

We can increase type safety in C++ by adding a single keyword. The
current proposal uses the keyword "only". [...]
What do you think?
I think that Haskell style newtype keyword or Ada style derived types would
server as well and would be a lot more useful.
 
R

red floyd

Jeff said:
Sorry, I misunderstood. When you say you "proposed something very
similar," I guess you mean adding a keyword, rather than using a template.

Actually, he wouldn't need to add a keyword. "explicit" could be
re-used instead of adding "only".
 
A

Alf P. Steinbach

* Jeff Schwab:
Sorry, I misunderstood. When you say you "proposed something very
similar," I guess you mean adding a keyword, rather than using a template.

No, I meant a template.

It was in the "Correct C++ Tutorial" (only tutorial referenced by the FAQ,
available at URL below).

As I recall, due to the responses I eventually I rewrote that section/chapter
removing the point list of ways to deal with that language rule botch-up,
because if any were mentioned then also the restrict-the-language approach would
have to be mentioned. But I'm not sure. May be there still.


Cheers,

- Alf
 
I

Ioannis Vranos

Ioannis said:
Proposal:

We can increase type safety in C++ by adding a single keyword. The
current proposal uses the keyword "only".


Example 1:

only int x= 4;

x= 5; // Ok

x= 5.0; // Error

x= 5U // Error



Example 2:

int i= 5;

only unsigned x= 4U;

x= 5; // Error

x= 5LU; // Error

x= i; // Error



Example 3:

only float f= 4.0F;

f= 4; // Error

f= 5.0; // Error

f= 4.0F; // OK




// It accepts any built in type
void somefunc(const int &x);


// It accepts only an int and a const int object
void somefunc(only const int &x);




It is simple like that, and the concept is backwards compatible.




What do you think?



More cases:

only double d1 = 1F; // That would be an error. Type mismatch (float assigned to double).


only double d2 = 1; // That would be an error. Type mismatch (int assigned to double).


d1 = 1F; // That would be an error. Type mismatch (float assigned to double).

d2 = 1; // That would be an error. Type mismatch (int assigned to double).


short s = 1; // That would be correct, since the keyword "only" is missing.



In the case of

only short s= 1;

it could be an error (type mismatch), if a postfix for short constants was provided, for example H/h.


short s= 1H; could work. And (UH/uh for unsigned short constants).


only int i = s; // That would be an error. Type mismatch (short assigned to int).

i = s; // That would be an error. Type mismatch (short assigned to int).



Another use of "only":


#include <iostream>


void somefunc(only int)
{
std::cout<< "somefunc(int) was called\n";
}


void somefunc(only double)
{
std::cout<< "somefunc(double) was called\n";
}



int main(void)
{
// OK, int is passed
somefunc(4);

// Error
somefunc(4U);

// OK, double is passed
somefunc(4.0);

// Error
somefunc(4.0F);

}
 
V

Victor Bazarov

Ioannis said:
Ioannis said:
Proposal:

We can increase type safety in C++ by adding a single keyword. The
current proposal uses the keyword "only".


Example 1:

only int x= 4;

x= 5; // Ok

x= 5.0; // Error

x= 5U // Error



Example 2:

int i= 5;

only unsigned x= 4U;

x= 5; // Error

x= 5LU; // Error

x= i; // Error



Example 3:

only float f= 4.0F;

f= 4; // Error

f= 5.0; // Error

f= 4.0F; // OK




// It accepts any built in type
void somefunc(const int &x);


// It accepts only an int and a const int object
void somefunc(only const int &x);




It is simple like that, and the concept is backwards compatible.




What do you think?



More cases:

[... effects of implementing the 'only' keyword ...]

I am yet to see the actual *problem* with any of those cases. Is your
suggestion just for the sake of changing the language, making an impact,
so to speak?

If you have encountered a *real-world* problem that cannot be solved
without adding your new mechanism for preventing implicit conversions
and promotions, could you please state it?

V
 
V

Vladyslav Lazarenko

More cases:

only double d1 = 1F;  // That would be an error. Type mismatch (float assigned to double).

only double d2 = 1; // That would be an error. Type mismatch (int assigned to double).

d1 = 1F;  // That would be an error. Type mismatch (float assigned to double).

d2 = 1;  // That would be an error. Type mismatch (int assigned to double).

short s = 1; // That would be correct, since the keyword "only" is missing.

In the case of

only short s= 1;

it could be an error (type mismatch), if a postfix for short constants was provided, for example H/h.

short s= 1H; could work. And (UH/uh for unsigned short constants).

only int i = s;  // That would be an error. Type mismatch (short assigned to int).

i = s;  // That would be an error. Type mismatch (short assigned to int).

Another use of "only":

#include <iostream>

void somefunc(only int)
{
     std::cout<< "somefunc(int) was called\n";

}

void somefunc(only double)
{
     std::cout<< "somefunc(double) was called\n";

}

int main(void)
{
     // OK, int is passed
     somefunc(4);

     // Error
     somefunc(4U);

     // OK, double is passed
     somefunc(4.0);

     // Error
     somefunc(4.0F);



}

I agree with Viktor. There are a lot of real-world problems where
implicit conversions of type hierarchies are extremely helpful. I
don't have a clue why you should deny them. It would be nice to see a
real-world problem where you need it.

Also, what do you think about denying explicit casting?
http://en.wikibooks.org/wiki/C++_Programming/Type_Casting
 
I

Ioannis Vranos

Victor said:
I am yet to see the actual *problem* with any of those cases. Is your
suggestion just for the sake of changing the language, making an impact,
so to speak?

If you have encountered a *real-world* problem that cannot be solved
without adding your new mechanism for preventing implicit conversions
and promotions, could you please state it?


What you say is a correct approach. I have to note here, that the proposal is a work in progress, and it
doesn't explain what happens with classes, class hierarchies, etc, yet.

The next thing to be added, is how the keyword would work in constructors.


Well, given the proposal as it currently is, an example of real world type safety problem, is having a
function returning a double:


only double somefunc()
{
double value= 1.0;

// Perform some operations
return value;
}



int main()
{
int x= somefunc(); // The compiler catches the error

}
 
V

Vladyslav Lazarenko

What you say is a correct approach. I have to note here, that the proposal is a work in progress, and it
doesn't explain what happens with classes, class hierarchies, etc, yet.

The next thing to be added, is how the keyword would work in constructors..

Well, given the proposal as it currently is, an example of real world type safety problem, is having a
function returning a double:

only double somefunc()
{
        double value= 1.0;

        // Perform some operations
        return value;

}

int main()
{
        int x= somefunc(); // The compiler catches the error
}

Ioannis,

I don't see any problem with that code at all. It might be a desired
behavior.

Assuming that "only double" keyword disables any kind of implicit
casting, I don't know why would someone need that, but Alf's solution
sounds better anyway. No need for extra keyword, just wrap that POD
type with a smart template and you are there.

Also, there is "auto" keyword in upcoming C++ standard. It solves
another problem, however, works out this case:

auto x = somefunc();

Look at http://en.wikipedia.org/wiki/C++0x
 
I

Ioannis Vranos

Vladyslav said:
Ioannis,

I don't see any problem with that code at all. It might be a desired
behavior.


Consider the following completely type-safe code:


#include <iostream>


only double somefunc()
{
only double value= 1.0;

// Perform some operations

return value;
}



int main()
{
using namespace std;

only double result= somefunc();

only int x= static_cast<int>(result);

cout<< x<< endl;
}


Also, an interesting thing to note, is that we can make the code backwards compatible (that is, valid
C++98/03) by using a single

#define only

statement.


Assuming that "only double" keyword disables any kind of implicit
casting,

You mean, "implicit conversion".


I don't know why would someone need that, but Alf's solution
sounds better anyway. No need for extra keyword, just wrap that POD
type with a smart template and you are there.

Also, there is "auto" keyword in upcoming C++ standard. It solves
another problem, however, works out this case:

auto x = somefunc();

Look at http://en.wikipedia.org/wiki/C++0x


Yes, the proposal will be fully compatible with C++0x.

In particular, when we use the keyword auto without a type, the keyword "only" can not be used.


Examples:

only auto int x= 5; // OK

only auto x= 5; // Compiler error. "only" cannot be used with keyword auto without a type specified.


auto is a weak typing approach, while "only" keyword is a strong typing approach.


I think for both to work cleanly and for simplicity, they shouldn't be combined (although they could under
specific circumstances).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top