Corrected: Proposal: Increasing type safety with a keyword

[Thomas J. Gritzan]

Updated http://www.cpp-software.net/documents/cpp_only_proposal.html
accordingly.

First, I think your comment is wrong:
"The new use of “auto†in upcoming C++0x, is a weak typing approach,
while "only" keyword is a strong typing approach."

The new "auto" is not less a strong typing approach than before (without
auto). You still can't change the type of a variable after declaration.
What "auto" does is called "type inference". It deduces the type of the
declared variable by the type of its initializer.

So an "only auto" variable would make sense:

only auto x = 5; // the type of x is "only int" now
x = 5.0; // can't assign double, because x is int.

Second, take a look at another proposal, for example the lambda proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf

Your proposal still lacks a motivation part (1.1 in the above) that
talks about **which problems you want to solve** with this solution, and
another part, which discusses why a simple library solution (some where
suggested) isn't good enough.

 

[Ioannis Vranos]

I decided to make this proposal an open proposal. What does this mean?

It means that everyone who contributes to this proposal, and he wishes to take credit for his contribution,
his personal information will be included in the final text of the proposal, if the proposal becomes complete.

That's why, everyone who will contribute to this proposal, and wants to take a credit for his contribution,
can provide the following personal information, along with his proposal contributions:


Name [Middle Name] Last name, email address, [web site], [postal address].


The information inside the brackets is optional.


The contributions must be mainly syntax-based, and must comply with the design aims at the top of the page:

http://www.cpp-software.net/documents/cpp_only_proposal.html


You can post your contributions to the proposal, in this discussion thread.

 

[Ioannis Vranos]

An answer of mine in another newsgroup:

>
> At a guess, you want an`only' keyword to mean that any
> initialization of or assignment to a variable must use an
> expression that is of the variable's exact type, without a
> conversion. Is that what you mean?
>
> One gap that seems evident is that you haven't specified
> what happens with type qualifiers. Do you intend to forbid
>
> only const char *p = "Hello, world!";

Yes, the proposal is under construction and doesn't cover all situations yet, however I think only

only const char * const p = "Hello, world!";

should compile, in this case (when we want to use the keyword "only").

> ... because the l.h.s. and r.h.s. disagree on const-ness?
> How about
>
> int i = 42;
> only void *q = &i;

"only" will not work with void pointers, in other words it would produce a compiler error.

This, because the aim of a void pointer is to be able to point to an object of any type, so it doesn't make
sense to use "only" with void pointers.

 

[Thomas J. Gritzan]

An answer of mine in another newsgroup:

Which one?
Cross-posting & follow-up would be a good idea.

Yes, the proposal is under construction and doesn't cover all situations
yet, however I think only

only const char * const p = "Hello, world!";

should compile, in this case (when we want to use the keyword "only").

"only" will not work with void pointers, in other words it would produce
a compiler error.

This, because the aim of a void pointer is to be able to point to an
object of any type, so it doesn't make sense to use "only" with void
pointers.

But a void pointer often is used pointing to raw memory, like in memory
allocators. Why do you want to propose a general type safety mechanism
and then forbid any useful usage?

 

[Ioannis Vranos]

First, I think your comment is wrong:
"The new use of “auto†in upcoming C++0x, is a weak typing approach,
while "only" keyword is a strong typing approach."

The new "auto" is not less a strong typing approach than before (without
auto). You still can't change the type of a variable after declaration.
What "auto" does is called "type inference". It deduces the type of the
declared variable by the type of its initializer.

I have updated http://www.cpp-software.net/documents/cpp_only_proposal.html

Take a look there for an explanation.

Second, take a look at another proposal, for example the lambda proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1968.pdf

Your proposal still lacks a motivation part (1.1 in the above) that
talks about **which problems you want to solve** with this solution, and
another part, which discusses why a simple library solution (some where
suggested) isn't good enough.

A small example how increased type safety helps us:


only double somefunc()
{
double value= 1.0;

// Perform some operations

return value;
}



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


The proposal solves the problem of reduced type-safety, and aims to become a completely type-safe solution,
without changing the use of existing features.


For more info, and an example of a complete type safe program, check the proposal web page:

http://www.cpp-software.net/documents/cpp_only_proposal.html

 

[Ioannis Vranos]

Yes, the proposal is under construction and doesn't cover all situations
yet, however I think only

only const char * const p = "Hello, world!";

should compile, in this case (when we want to use the keyword "only").

But it won't because string literals are of type < const char[] >.

The code:

const char * const p = "Hello, world!";

is valid C++98/03.

But a void pointer often is used pointing to raw memory, like in memory
allocators. Why do you want to propose a general type safety mechanism
and then forbid any useful usage?

The void pointers were designed to point anywhere. Assigning a void pointer value to another type pointer
variable, always requires a cast under C+98/03, and keyword "only" will not interfere with that.

In other words, void pointers are designed to be unsafe (they point to an object of *any* type), so they
cannot be used together with keyword "only".

 

[Noah Roberts]

A small example how increased type safety helps us:


only double somefunc()
{
double value= 1.0;

// Perform some operations

return value;
}



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

I don't know of a single compiler that would allow you to do this
without warning; I think they're required to. Most compilers have a
switch that allows you to make warnings an error. I think, perhaps,
that this is more what you want to illustrate:

int somefunc();
int main()
{
only double x = somefunc(); // error
}

I just don't see why that would help you. Furthermore, I'd very much
recommend against anything like this:

only int somefunc();

It's the caller's responsibility what to do with the information
returned by "somefunc", including to totally ignore it. Something like
this has a bit of a smell to it. Normally you have preconditions that
must be met before the function can be called, and postconditions that
must be supplied by the function. I've never heard of imposing
post-conditions that must be met by the client, yet that's what you seem
to be proposing by putting only in the declaration of the function.

In short, I wouldn't support such code and I see no useful purpose for
this language extension. If you really want this kind of behavior you
can get it from BOOST_STRONG_TYPEDEF.

 

[Ioannis Vranos]

I don't know of a single compiler that would allow you to do this
without warning; I think they're required to. Most compilers have a
switch that allows you to make warnings an error.

The code:


double somefunc()
{
double value= 1.0;

// Perform some operations

return value;
}



int main()
{
int x= somefunc();
}


john@ubuntu:~/Projects/anjuta/cpp/src$ g++ -ansi -pedantic-errors -Wall main.cc -o foobar
main.cc: In function ‘int main()’:
main.cc:14: warning: unused variable ‘x’
john@ubuntu:~/Projects/anjuta/cpp/src$


So now you know one compiler that allows this without a warning.


john@ubuntu:~/Projects/anjuta/cpp/src$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu12)
john@ubuntu:~/Projects/anjuta/cpp/src$

I think, perhaps,
that this is more what you want to illustrate:

int somefunc();
int main()
{
only double x = somefunc(); // error
}

I just don't see why that would help you. Furthermore, I'd very much
recommend against anything like this:

only int somefunc();

It's the caller's responsibility what to do with the information
returned by "somefunc", including to totally ignore it. Something like
this has a bit of a smell to it.

If the programmer wants not having type safety on the returned type, he can define the function without the
keyword only, in the following style:


double somefunc()
{
only double value= 1.0;

// Perform some operations

return value;
}



int main()
{
int i= somefunc(); //OK

double d= somefunc(); //OK

only double od= somefunc(); // OK
}


So noone forces the programer to define the function returning "only double". In other words, the feature does
not get in the way of the programmer if he wishes not using it.

Normally you have preconditions that
must be met before the function can be called, and postconditions that
must be supplied by the function. I've never heard of imposing
post-conditions that must be met by the client, yet that's what you seem
to be proposing by putting only in the declaration of the function.

If you do not want to use this type-safe ability of returning a value, you may not use it, while you may use
other abilities of "only", if you want.

 

[Victor Bazarov]

[..]
If the programmer wants not having type safety on the returned type, he
can define the function without the keyword only, in the following style:


double somefunc()
{
only double value= 1.0;

// Perform some operations

return value;
}



int main()
{
int i= somefunc(); //OK

double d= somefunc(); //OK

only double od= somefunc(); // OK
}


So noone forces the programer to define the function returning "only
double". In other words, the feature does not get in the way of the
programmer if he wishes not using it.

Yes, aside from the fact that there is a new keyword...

I am still holding my breath for the rationale (and not consequences)
for this change. Any idea when you're going to come up with one?

V

 

[Noah Roberts]

If you do not want to use this type-safe ability of returning a value,
you may not use it, while you may use other abilities of "only", if you
want.

I'm sorry, the argument that I don't have to use something just because
it's there is not sufficient for me to be convinced it should be added
to the language. I could say that about a lot of useless things.

Thanks anyway.

 

[Ioannis Vranos]

[..]
If the programmer wants not having type safety on the returned type,
he can define the function without the keyword only, in the following
style:


double somefunc()
{
only double value= 1.0;

// Perform some operations

return value;
}



int main()
{
int i= somefunc(); //OK
double d= somefunc(); //OK
only double od= somefunc(); // OK }


So noone forces the programer to define the function returning "only
double". In other words, the feature does not get in the way of the
programmer if he wishes not using it.

Yes, aside from the fact that there is a new keyword...

I am still holding my breath for the rationale (and not consequences)
for this change. Any idea when you're going to come up with one?

From http://www.cpp-software.net/documents/cpp_only_proposal.html:


"Why we need increased type safety: We need increased type safety, so as the compiler can help us avoid
mistakes and thus bugs in our code. Why a library solution isn't better: Because it would be too complex and
more limited, in comparison to the keyword based solution".

 

[Ioannis Vranos]

I'm sorry, the argument that I don't have to use something just because
it's there is not sufficient for me to be convinced it should be added
to the language. I could say that about a lot of useless things.

Thanks anyway.

Don't you think that the code:


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()
{

// OK, int is passed
somefunc(4);


// Error
somefunc(4U);


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


// Error
somefunc(4.0F);
}


is more type-safe than the code:


include <iostream>


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


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


int main()
{

// OK, int is passed
somefunc(4);


// Mistake, but compiles.
somefunc(4U);


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


// Mistake, but compiles.
somefunc(4.0F);
}

 

[Noah Roberts]

is more type-safe than the code:

No. I can't reproduce your results. Not with g++ 3 anyway. Will check
4 when I get home.

include <iostream>


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


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


int main()
{
// Mistake, but compiles.
somefunc(4U);
}

Have you actually attempted to compile this code? Fails to resolve
ambiguity here. That's the only line that's mildly objectionable. I
don't consider the passing of a float into a double to be a type safety
issue.

 

[Ioannis Vranos]

You have not made the case that your proposal adds type safety. If you
want types that don't support implicit conversions, they're easy enough
to write. It is not clear that the keyword buys you anything.


Could you provide an example?

class SomeClass
{
public:
SomeClass(int);
SomeClass(const SomeClass &);
};


int main()
{
SomeClass obj1= 5; // OK

SomeClass obj2= obj1; // OK

only SomeClass obj3= 5; // Compiler Error.

only SomeClass obj4= obj1; // OK
}

 

[Ioannis Vranos]

Have you actually attempted to compile this code? Fails to resolve
ambiguity here. That's the only line that's mildly objectionable. I
don't consider the passing of a float into a double to be a type safety
issue.

Thanks for reporting the mistake, I fixed the code.


I have to note something here: Everything that is relative to type-safety, and is effective in C++98/03,
continues to be effective under the "only" proposal.

The additional type safety via the new keyword "only", will be under the programmer's willingness to use it or
not.

The use of "only", does not prohibit the programmer to assign the value of a type to another type, it simply
requires him to specify his intentions explicitly.

 

[Ioannis Vranos]

Ioannis Vranos wrote:

Yes, the proposal is under construction and doesn't cover all
situations yet, however I think only

only const char * const p = "Hello, world!";

should compile, in this case (when we want to use the keyword
"only").
But it won't because string literals are of type < const char[] >.

The code:

const char * const p = "Hello, world!";

is valid C++98/03.

This is valid code because of an implicit conversion - which you want to
ban for some unclear reason.

The proposal is still a work in progress, and it doesn't cover pointers yet, however the assignment

only const char * const p = "Hello, world!";


will be valid.

 

[Thomas J. Gritzan]

From http://www.cpp-software.net/documents/cpp_only_proposal.html:


"Why we need increased type safety: We need increased type safety, so as
the compiler can help us avoid mistakes and thus bugs in our code.

Why do we need increased type safety?

Why a
library solution isn't better: Because it would be too complex and more
limited, in comparison to the keyword based solution".

That's wrong. A library solution would be less complex, since the ~10
lines of code could be written once and distributed to all users, while
a core languages solution would have to be implemented in _all_ C++
compilers.
It's also less limited but more flexible, since we can easily adjust the
library solution if the situation changes or we find that the current
semantics are wrong in specific cases.

You won't convince anybody of your proposal by saying "we need it,
because we need it!"

 

[Ioannis Vranos]

Why do we need increased type safety?

Less programming mistakes.

 

[Victor Bazarov]

[..]
If the programmer wants not having type safety on the returned type,
he can define the function without the keyword only, in the following
style:


double somefunc()
{
only double value= 1.0;

// Perform some operations

return value;
}



int main()
{
int i= somefunc(); //OK
double d= somefunc(); //OK
only double od= somefunc(); // OK }


So noone forces the programer to define the function returning "only
double". In other words, the feature does not get in the way of the
programmer if he wishes not using it.

Yes, aside from the fact that there is a new keyword...

I am still holding my breath for the rationale (and not consequences)
for this change. Any idea when you're going to come up with one?

From http://www.cpp-software.net/documents/cpp_only_proposal.html:


"Why we need increased type safety: We need increased type safety,

You keep repeating this, as if the more you say it, the more it would
make sense. But it doesn't. "Increased type safety" is meaningless
without the problem for which it's beneficial. I say the type safety at
the levels we already have is enough for any task out there. You seem
to say that it isn't. Please give the example where the "increase type
safety" is *required*. And please don't post those "foo(1U); // error"
any more, they are *not* the real world problems. What problem is out
there which requires you to make calling 'foo(int)' illegal with an
unsigned argument and is not already flagged by the compiler?

Please be specific.

> so as
the compiler can help us avoid mistakes and thus bugs in our code. Why a
library solution isn't better: Because it would be too complex and more
limited, in comparison to the keyword based solution".

V

 

[Thomas J. Gritzan]

Yes, the proposal is under construction and doesn't cover all situations
yet, however I think only

only const char * const p = "Hello, world!";

should compile, in this case (when we want to use the keyword "only").

But it won't because string literals are of type < const char[] >.

The code:

const char * const p = "Hello, world!";

is valid C++98/03.

Just like

double d = 5;

is valid C++98/03, but with

only double d = 5;

won't compile. So why should

only const char * const p = "Hello, world!";

compile then? Any reason for this exception?

The void pointers were designed to point anywhere. Assigning a void
pointer value to another type pointer variable, always requires a cast
under C+98/03, and keyword "only" will not interfere with that.

In other words, void pointers are designed to be unsafe (they point to
an object of *any* type), so they cannot be used together with keyword
"only".

But "only" is designed to make things more safe. Why not allow making an
unsafe type more safe by allowing "only void*", so that specific
pointers "T*" won't be implicitly convertible to it?