Corrected: Proposal: Increasing type safety with a keyword

[Victor Bazarov]

Thomas J. Gritzan wrote:
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.

BTW, it's not "assignment". It's initialisation. Just so we're on the
same page.

V

 

[Ioannis Vranos]

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.

In comp.lang.c one can find people who ask "why do we need C++"?

They "do not need" even function overloading to be adopted in C.

 

[Victor Bazarov]

In comp.lang.c one can find people who ask "why do we need C++"?

They "do not need" even function overloading to be adopted in C.

Uh... I am slow today. Were you making some point with that? Why
don't we add SQL query handling to C++ preprocessor? Or image
recognition capabilities? The existence of the feature elsewhere or
even its niceness is not enough justification to include it in the language.

So, let's start over. What problem do you solve with your addition to
the language that cannot be solved with already existing mechanisms?

V

 

[Ioannis Vranos]

Uh... I am slow today. Were you making some point with that? Why
don't we add SQL query handling to C++ preprocessor? Or image
recognition capabilities? The existence of the feature elsewhere or
even its niceness is not enough justification to include it in the
language.

So, let's start over. What problem do you solve with your addition to
the language that cannot be solved with already existing mechanisms?

More type safety means fewer programming errors. Do you agree with this?

 

[Victor Bazarov]

More type safety means fewer programming errors. Do you agree with this?

....and even more type safety means even fewer programming errors, right?

Does that mean that strongly typed language with no implicit conversions
provides full protection against programming errors? No. So, I can
only agree with your statement to some degree. To what degree, you'd
ask. And I'd say, to the degree that C++ *already has*. More *than
already exists in the language* does *not* mean fewer errors. At this
point in C++'s development as a language *I* don't see the need in what
you're proposing. (I guess by now you've gathered that much). Now, you
have a change (this is, like, the umpteenth time I'm asking about it) to
prove to me that there exists *a problem*, a *concrete* problem, that
your change would help solve, and that cannot be solved by the existing
mechanisms of the language. And every time I ask about it, you start
puffing hot air about "type safety" and wave your arms around. This is
the last time, after which, if I don't read a coherent reply to my
inquiry, I'll consider the discussion *over*, and advise you to take up
the career in politics, where there is no responsibility, only
arm-waving and hot air. And I'll have to probably killfile you as a
troll. Nothing personal.

Do you understand what I'm asking?

V

 

[Ioannis Vranos]

Does that mean that strongly typed language with no implicit conversions
provides full protection against programming errors? No. So, I can
only agree with your statement to some degree. To what degree, you'd
ask. And I'd say, to the degree that C++ *already has*. More *than
already exists in the language* does *not* mean fewer errors. At this
point in C++'s development as a language *I* don't see the need in what
you're proposing. (I guess by now you've gathered that much). Now, you
have a change (this is, like, the umpteenth time I'm asking about it) to
prove to me that there exists *a problem*, a *concrete* problem, that
your change would help solve, and that cannot be solved by the existing
mechanisms of the language. And every time I ask about it, you start
puffing hot air about "type safety" and wave your arms around. This is
the last time, after which, if I don't read a coherent reply to my
inquiry, I'll consider the discussion *over*, and advise you to take up
the career in politics, where there is no responsibility, only
arm-waving and hot air. And I'll have to probably killfile you as a
troll. Nothing personal.

Do you understand what I'm asking?

At http://en.wikipedia.org/wiki/Comparison_of_programming_languages, check the second table about type safety
and C++.

I have already provided some examples from the current state of the proposal, but if you do not consider them
as type-safety examples that reduce the risk of errors, ==> perhaps you should wait until the proposal gets
more complete (and covers Object Oriented programming for example), and thus more examples will be given then.


Here are some examples, given the current state of the proposal, including some principles that I will add
tomorrow or later to the web page of the proposal:


Example 1:


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


int main()
{
SomeClass obj1= 5; // OK, "only" is not used

SomeClass obj2= obj1; // OK, "only" is not used


only SomeClass obj3= 5; // Compiler Error.

only SomeClass obj4(5); // OK

only SomeClass obj5= obj1; // OK

int x; // OK, "only" is not used

only int i1; // error, "only" objects must be initialised always.

only int i2= 5; // OK

}


Example 2:


char *p= "Text"; // OK, "only" is not used

only char *p= "Text"; // Compiler Error

only const char *p= "Text"; // OK

only const char * const p= "Text"; // OK

char * const p= "Text"; // OK,"only" is not used

only char * const p= "Text"; // Compiler Error

 

[Ioannis Vranos]

Today I updated the text with significant changes. Rules have been relaxed, and the implicit integer/floating
point promotions issue has been solved (I think).


The text, which is a work in progress, can be found here:

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


(press Ctrl-Refresh in your browser, to make sure you see the most recent version of the page).


Any comments, corrections and contributions are welcomed.


As mentioned in the page, anyone that contributes to the proposal and wishes to take credit for his
contributions, if the proposal gets completed, he can follow the directions mentioned at the end of the page.


Thanks.

 

[Bart van Ingen Schenau]

At http://en.wikipedia.org/wiki/Comparison_of_programming_languages, check the second table about type safety
and C++.

Have you also checked http://en.wikipedia.org/wiki/Type_safety and
http://en.wikipedia.org/wiki/Type_system#Safely_and_unsafely_typed_systems,
where it is described what is meant by type safety?
When you do, you will see that implicit conversions do not affect type
safety but that the lack of type safety in C and C++ is the result of
the unrestricted use of pointers that C and C++ allow combined with
the manual memory management.

Bart v Ingen Schenau

 

[Ioannis Vranos]

Have you also checked http://en.wikipedia.org/wiki/Type_safety and
http://en.wikipedia.org/wiki/Type_system#Safely_and_unsafely_typed_systems,
where it is described what is meant by type safety?
When you do, you will see that implicit conversions do not affect type
safety but that the lack of type safety in C and C++ is the result of
the unrestricted use of pointers that C and C++ allow combined with
the manual memory management.

Thank you for the links. The proposal is actually a compile-time type-safety feature, and I have just updated
the web page to reflect that.


From the first link "Type safety", I think the following (which are not all the features mentioned in that
page) are accomplished so far (the proposal is a work in progress), without sacrificing the expressiveness of
C++98/03:


"most definitions involve the use of a type system to prevent certain erroneous or undesirable program
behavior (called type errors)".

"The enforcement can be static, catching potential errors at compile time, or dynamic, associating type
information with values at run time and consulting them as needed to detect imminent errors, or a combination
of both".

"The behaviors classified as type errors by a given programming language are usually those that result from
attempts to perform an operation on some values, that is not appropriate to their data types.
[...]
, while others consider any contravention of the programmer's intent (as communicated via typing annotations)
to be erroneous and deserving of the label "unsafe"".

"In the context of static type systems, type safety usually involves (among other things) a guarantee that the
eventual value of any expression will be a legitimate member of that expression's static type".

"Most statically-typed languages provide a degree of type safety that is strictly stronger than memory safety,
because their type systems enforce the proper use of abstract data types defined by programmers even when this
is not strictly necessary for memory safety or for the prevention of any kind of catastrophic failure".


The last one is one I am thinking about currently:

"A well typed program never gets "stuck", i.e., never gets into an undefined state where no further
transitions are possible".


This means we must have all compile-time type-safe variables initialised with a value.



Example:


int x; // OK, "only" is not used.

only int i1; // Error, "only" objects must be initialised always.

only int i2= 5; // OK


Regarding the second link "Safely and unsafely typed systems", I think the keyword "only", compile-time
type-safety solution accomplishes this.



More specifically I think it accomplishes in a high degree, the following:


"A third way of categorizing the type system of a programming language uses the safety of typed operations and
conversions. Computer scientists consider a language "type-safe" if it does not allow operations or
conversions which lead to erroneous conditions".

 

[Vladyslav Lazarenko]

...and even more type safety means even fewer programming errors, right?

Does that mean that strongly typed language with no implicit conversions
provides full protection against programming errors?  No.  So, I can
only agree with your statement to some degree.  To what degree, you'd
ask.  And I'd say, to the degree that C++ *already has*.  More *than
already exists in the language* does *not* mean fewer errors.  At this
point in C++'s development as a language *I* don't see the need in what
you're proposing.  (I guess by now you've gathered that much).  Now, you
have a change (this is, like, the umpteenth time I'm asking about it) to
prove to me that there exists *a problem*, a *concrete* problem, that
your change would help solve, and that cannot be solved by the existing
mechanisms of the language.  And every time I ask about it, you start
puffing hot air about "type safety" and wave your arms around.  This is
the last time, after which, if I don't read a coherent reply to my
inquiry, I'll consider the discussion *over*, and advise you to take up
the career in politics, where there is no responsibility, only
arm-waving and hot air.  And I'll have to probably killfile you as a
troll.  Nothing personal.

Do you understand what I'm asking?

V

I agree with Viktor and Bart and consider this as a proposal without
any reasonable motivation. C++ type system is extremely strong except
those cases described by Bart. Let's close this discussion.

 

[Ioannis Vranos]

I agree with Viktor and Bart and consider this as a proposal without
any reasonable motivation. C++ type system is extremely strong except
those cases described by Bart. Let's close this discussion.

May I ask if you consider the new use of keyword "auto" in C++0x, necessary then?

 

[Vladyslav Lazarenko]

May I ask if you consider the new use of keyword "auto" in C++0x, necessary then?

Sure. One of the real problems is to express a type of return value of
template function. For example, try to store a result of "bind"
function from Boost.Bind library into some variable. Even if you
succeeded after few hours (most probably - days) of source code
investigation, replace that function with Boost.Lambda and you will
have to start all over again.

Here is some code example:

class A {
int i;
public:

A(int ii) : i(ii) {};
void set_i(int x) { i = x; }
};

A a;
__WHAT_TYPE_GOES_HERE__??? my_foo = bind(&A::set_i, ref(a), _1)

Please read more at http://en.wikipedia.org/wiki/C++0x

 

[Alf P. Steinbach]

* Ioannis Vranos:

May I ask if you consider the new use of keyword "auto" in C++0x,
necessary then?

The 'auto' keywords solves a real problem, that of otherwise having to repeat a
very long-winded, sometimes thousands of characters, and sometimes in practice
unknowable, type designation.

You

* haven't provided any use case for your 'only' keyword, you have

* ignored articles (including mine and Jeff's) showing how to easily do the
same within the current language, and you have

* multi-posted the discussion to two different groups plus web site.

Now I could easily put up some use cases convincing most people that this
/functionality/ (but not the keyword proposal) is needed, and it amazes me that
you, who makes such a proposal, has been unable to come up with them.

Be that as it may -- it's an honest thing and not unusual that the example
generator circuit refuses to come up with anything even though one remembers
having to deal with such (vaguely) earlier -- you really shouldn't have
ignored articles showing alternatives to your proposal.

That's a good way to be ignored in turn.

Multi-posting and web'ifying, which was the second measure you took in that
direction, is perhaps just as effective for that.


Cheers & hth.,

- Alf

 

[Noah Roberts]

Today I updated the text with significant changes. Rules have been
relaxed, and the implicit integer/floating point promotions issue has
been solved (I think).


The text, which is a work in progress, can be found here:

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

Might I suggest something?

After having reviewed your website it's clear to me that you're
basically a beginner. You might be past the tutorial stage, to the
point of actually being able to answer questions for other beginners,
but you've got a really long way to go. You not only need deeper
understanding of programming in C++ but also in effectively writing
technical specs and articles. You're also obviously lacking in the
politics and persuasion skills you would need to address an
international committee.

My suggestion is that perhaps attempting to make this major leap to
experthood without the experience and knowledge needed to succeed is a
mistake. My other suggestion is that perhaps you should consider more
thoughtfully the statements of experts you've heard from here in this
thread.

My final suggestion is to note that the STD committee will probably try
being polite about telling you to bugger off, maybe, but if you persist
and insist like you've done here you're going to make a huge ass of
yourself...just as you've done here.

I'd say it's worth the practice but you're not listening to anyone so
it's basically a waste of everyone's time.

 

[Ioannis Vranos]

Sure. One of the real problems is to express a type of return value of
template function. For example, try to store a result of "bind"
function from Boost.Bind library into some variable. Even if you
succeeded after few hours (most probably - days) of source code
investigation, replace that function with Boost.Lambda and you will
have to start all over again.

Here is some code example:

class A {
int i;
public:

A(int ii) : i(ii) {};
void set_i(int x) { i = x; }
};

A a;
__WHAT_TYPE_GOES_HERE__??? my_foo = bind(&A::set_i, ref(a), _1)

Please read more at http://en.wikipedia.org/wiki/C++0x

At first I have to note that we are having an interesting friendly discussion about programming, and not a
controversy.


Well, I think one may specify the returned value in the style:


template <class ReturnType, class T>
ReturnType SomeFunction(const T& x)
{
ReturnType someValue;

// Do things with x

return someValue; // someValue is of type ReturnType
}


int main()
{
double x= SomeFunction<double>(5);
}


Regarding "only" proposal, this case shows me why the type-safety of returned value is important, a thing that
someone questioned elsewhere in the thread (just checked, Noah Roberts).

 

[Ioannis Vranos]

* Ioannis Vranos:

The 'auto' keywords solves a real problem, that of otherwise having to
repeat a very long-winded, sometimes thousands of characters, and
sometimes in practice unknowable, type designation.

You

* haven't provided any use case for your 'only' keyword, you have

* ignored articles (including mine and Jeff's) showing how to easily
do the
same within the current language, and you have

* multi-posted the discussion to two different groups plus web site.

Now I could easily put up some use cases convincing most people that
this /functionality/ (but not the keyword proposal) is needed, and it
amazes me that you, who makes such a proposal, has been unable to come
up with them.

Be that as it may -- it's an honest thing and not unusual that the
example generator circuit refuses to come up with anything even though
one remembers having to deal with such (vaguely) earlier -- you really
shouldn't have ignored articles showing alternatives to your proposal.

That's a good way to be ignored in turn.

Multi-posting and web'ifying, which was the second measure you took in
that direction, is perhaps just as effective for that.

Regarding multiposting, why is it forbidden to post to relevant groups for a subject?

Reagrding "webifying", I keep my proposal as a web page, accessible to me and to all with whom I discuss, so
as to have a specific uptodate reference for my proposal. Why is this bad? Should I post my whole proposal
with its new additions, modifications and corrections to the thread, at every change I make?


Third, I am not ignoring anyone. I was provided with a template solution "else-thread", which did not compile
with g++, and I did not get a corrected reply. May you provide the messages I "ignored"?

 

[Noah Roberts]

Vladyslav Lazarenko wrote:
At first I have to note that we are having an interesting friendly
discussion about programming, and not a controversy.


Well, I think one may specify the returned value in the style:


template <class ReturnType, class T>
ReturnType SomeFunction(const T& x)
{
ReturnType someValue;

// Do things with x

return someValue; // someValue is of type ReturnType
}


int main()
{
double x= SomeFunction<double>(5);
}

This is a perfect example of what I mean. I think people are getting
upset here because it seems you are ignoring them when I think the real
problem is that you don't actually understand the replies. You just so
completely missed the point that it's pretty clear, to me at least, that
you simply don't know anything about what you're trying to talk about.

 

[Ioannis Vranos]

Might I suggest something?

After having reviewed your website it's clear to me that you're
basically a beginner. You might be past the tutorial stage, to the
point of actually being able to answer questions for other beginners,
but you've got a really long way to go. You not only need deeper
understanding of programming in C++ but also in effectively writing
technical specs and articles. You're also obviously lacking in the
politics and persuasion skills you would need to address an
international committee.

My suggestion is that perhaps attempting to make this major leap to
experthood without the experience and knowledge needed to succeed is a
mistake. My other suggestion is that perhaps you should consider more
thoughtfully the statements of experts you've heard from here in this
thread.

Of course I consider all the statements here, that's why I created this discussion thread.

My final suggestion is to note that the STD committee will probably try
being polite about telling you to bugger off, maybe, but if you persist
and insist like you've done here you're going to make a huge ass of
yourself...just as you've done here.

I'd say it's worth the practice but you're not listening to anyone so
it's basically a waste of everyone's time.

Having you disagreeing with the proposal, doesn't mean that I have to agree with you. But I did not say the
proposal will ever get completed.

In fact if you notice at the bottom of the page:

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


I have been mentioning since some time:

"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".


So I am not sure if the proposal gets completed. It may be unneeded indeed, or it may turn to something else,
like increasing compiler warnings in specific cases. It is something like an experiment project which may turn
to something useful, but it may not.


What is certain is that in the end of the process, if it does not get completed, I will provide a pdf with the
proposal as it will be then, probably under GNU Free Documentation License (as a free document).

It may be useful for future use of someone else, for something similar or something else.

 

[Alf P. Steinbach]

* Ioannis Vranos:

Regarding multiposting, why is it forbidden to post to relevant groups
for a subject?

It's not forbidden.

It's just very counter-productive, especially when none of threads refer to the
others.

As to the "why" I've given you a link earlier, in the other group you posted to.

Reagrding "webifying", I keep my proposal as a web page, accessible to
me and to all with whom I discuss, so as to have a specific uptodate
reference for my proposal. Why is this bad? Should I post my whole
proposal with its new additions, modifications and corrections to the
thread, at every change I make?

That would be a good idea for a new proposal. And then not make small changes.
Versions.

Third, I am not ignoring anyone. I was provided with a template solution
"else-thread", which did not compile with g++, and I did not get a
corrected reply. May you provide the messages I "ignored"?

Search for my name and for Jeff Schwab in any archive of this thread.


Cheers & hth.,

- Alf

 

[Ioannis Vranos]

It's not forbidden.

It's just very counter-productive, especially when none of threads refer
to the others.

As to the "why" I've given you a link earlier, in the other group you
posted to.

Just search in newsgroups at google, the word "cross-posting":

http://groups.google.gr/groups/search?hl=en&q=crossposting&qt_s=Search+Groups


I support the notion of multi-posting and not cross-posting, because at some point (including the beginning)
the discussion may become offtopic, while at the same time, people who consider cross-posting "bad" and
multi-posting "good" like me, post a reply only to "their" newsgroup (I don't follow this practice myself).

That would be a good idea for a new proposal. And then not make small
changes. Versions.

Well, I have news for you. There is a new thing called the web, which is more useful than this practice. In
fact, I considered creating a wiki page for the proposal, so as people to be able to contribute easily, but I
left that idea aside so far.

An updated web page is a better reference than individual messages with the same stuff, especially for
discussions in moderated newsgroups and forums, where messages wait for approval, and other people reply to
something you have already changed.

In fact, I began this discussion thread with your recommended approach, and then it became obvious that a web
page is far better for this.

Search for my name and for Jeff Schwab in any archive of this thread.

I will do it and post replies.