Re: A new notion: stronglly-typed-by-user language

[Maciej Sobczak <see.my.homepage@gmail.com>]

On 17 Kwi, 20:57, "J-P. Rosen" <ro...@adalog.fr> wrote:

> Precisely. You showed you can add type safety to the language - which
> means that there is not built-in type safety.

No. I have shown that the language is capable of supporting user-
defined integer types. There is nothing *added* to the language -
everything is plain vanilla standard C++.

That is, there was nothing missing in there.

> Here is what I had in mind. If you have:
> void p (short S);
> void p (long L);
> and you call p (I) where I is an int, it will resolve to the first one
> if short and int are the same, and to the second one if long and int are
> the same. This is logical

No. Not only it is not logical - it will not even compile.

First of all, type int is never subject to promotion. "Lower" types
can be promoted to int if necessary and this is promotion. Apart from
this, integer types can be converted between each other.
Promotion has higher rank than conversion in overload resolution and
this is basically the only place where the distinction between them is
relevant.
That is:

void foo(char) {}
void foo(int) {}

short s = 42;
foo(s); // this calls foo(int),
        // because promotion short->int is possible
        // and has a higher rank
        // than conversion short->char.

Your example above cannot compile, because the actual parameter int
cannot be promoted to long (int is never promoted, only "lower" types
are) and its conversion to either short or long has equal rank -
therefore the call is ambiguous.

This has *nothing* to do with representation - these types are all
different even if they have the same representation.

> the idea that
> overloading resolution (and the associated promotion) depends on the
> implementation will make any Ada lawyer faint ;-)

Overload resolution does *not* depend on implementation in C++, it is
precisely defined with no relation to representation.

> > There are many bad ideas in C++. I don't see how this one affects
> > strong type safety.
>
> See above

I still don't see how this or anything else that was mentioned since
the beginning of this thread affects strong type safety. Especially
when the presented arguments are incorrect.


OK. I'm a C++ programmer and I know how to answer my question. I'm
actually surprised that nobody came up with valid explanation of why C+
+ sucks for so long, yet many people were ready to make fun of C++ as
a language that obviously must suck. This shows that there is a
significant bias component in your argumentation and that makes it
(the argumentation) much less effective.
In other words, you can use it to "preach to the choir", but you
cannot use it to reach to an audience that might actually benefit from
what you want to say.

Just imagine - what would happen if there was a C++ programmer on your
tutorial and you presented these arguments? ;-) ;-) ;-)


Here is a valid argument that you can use:

1. C++ as a language has a *subset* that supports strong type safety
in the sense that it is not possible to modify the value of any type
by bypassing the interface of that type. If you stick to that language
subset, you are safe.

2. C++ also has some features that allow to undermine the type safety
by means of untyped or loosely typed *aliases*. In particular, pointer
arithmetic (this includes all kinds of buffer overflows), conversions
through void*, reinterpret_casts, unions and dangling pointers all
allow to modify values of type T by means that are outside of T's
interface and *that* is what makes the whole language unsafe and the
sad reality is that these features are too frequently used - most
likely because they are too easy to use.

You can use point 1. if you want to convince someone that it is
possible to build a reliable system in C++. There are people who
believe in it and there are such systems.
You can use point 2. to convince someone that C++ is not the best
choice when support for reliability is required. The argument about
untyped aliases is valid and widely acknowledged - even within the C++
community, and if anybody objects you can refer to any well known
security vulnerability to make your point. This can create an
opportunity to later highlight the advantages of Ada and perhaps
recruit some new Ada converts.

I hope that this will allow you to better address your audiences.
Even if there is a C++ programmer listening. ;-)

--
Maciej Sobczak * http://www.inspirel.com

YAMI4 - Messaging Solution for Distributed Systems
http://www.inspirel.com/yami4