Corrected: Proposal: Increasing type safety with a keyword

[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);



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 <stdio.h>


void somefunc1(only int x)
{
printf("somefunc(int) was called\n");
}


void somefunc2(only double x)
{
printf("somefunc(double) was called\n");
}



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

/* Error */
somefunc1(4U);

/* OK, double is passed */
somefunc2(4.0);

/* Error */
somefunc2(4.0F);


return 0;
}



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

 

[Ioannis Vranos]

This proposal was a port to C, of a C++ proposal that is no complete yet.

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


When it gets completed, I may post an equivalent C one here.

Also there are many great things that could be adopted in C, function overloading, template functions, etc.


So please ignore this thread for the moment.

 

[Eric Sosman]

Proposal:

We can increase type safety in C by adding a single keyword. The current
proposal uses the keyword "only".
[... assorted examples, no actual proposal ...]

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!";

.... because the l.h.s. and r.h.s. disagree on const-ness?
How about

int i = 42;
only void *q = &i;

.... where the types of the l.h.s. and r.h.s. are different?

> It is simple like that, [...]

Perhaps not quite so simple, after all. Even so, it seems
to me that there's a far harder task before you than revealing
the beauteous simplicity of the idea: You've got to provide some
evidence that the new keyword does in fact make things easier or
safer or in some other way "better" than C as it stands. Thus
far I'm not convinced, and I think the committee may be even
harder to convince than I am.

 

[Ioannis Vranos]

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.

... where the types of the l.h.s. and r.h.s. are different?

It is simple like that, [...]

Perhaps not quite so simple, after all. Even so, it seems
to me that there's a far harder task before you than revealing
the beauteous simplicity of the idea: You've got to provide some
evidence that the new keyword does in fact make things easier or
safer or in some other way "better" than C as it stands. Thus
far I'm not convinced, and I think the committee may be even
harder to convince than I am.

You may have a look at the proposal anytime as it evolves, at
http://www.cpp-software.net/documents/cpp_only_proposal.html


I repeat, that this is a C++ proposal, and if it gets finished, perhaps I will post an equivalent one for C,
in c.l.c..

 

[Eric Sosman]

[...]
I repeat, that this is a C++ proposal, and if it gets finished, perhaps
I will post an equivalent one for C, in c.l.c..

Have you any COBOL proposals you'd like to share?

 

[vippstar]

Proposal:

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

<snip rest>

We can. Should we?
I don't think such nonsense belongs to the language. It's more
appropriate to use a tool (like lint, but I don't think lint does
this) that warns you about it.

 

[Phil Carmody]

Ioannis Vranos said:

This proposal fills a much-needed gap.

The needle on my needometer barely twitched.

However, the usefulness of his suggestion cannot be understated.

Phil

 

[Richard Bos]

This proposal was a port to C, of a C++ proposal that is no complete yet.

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

This is (for C at least; I have no opinion about C++) a bad idea.

Also there are many great things that could be adopted in C, function overloading, template functions, etc.

These, by contrast, are _exceedingly_ bad ideas.

Richard