"C++ Creator Bjarne Stroustrup Weighs in on Distributed Systems, Type Safety and Rust"

[Lynn McGuire]

"C++ Creator Bjarne Stroustrup Weighs in on Distributed Systems, Type
Safety and Rust" by David Cassel

https://thenewstack.io/c-creator-bjarne-stroustrup-weighs-in-on-distributed-systems-type-safety-and-rust/

"In June the creator of the C++ programming language, 69-year-old Bjarne
Stroustrup, appeared on YouTube’s channel on behalf of the Association
for Computing Machinery’s Special Interest Group on Programming Languages."

"Some 35 years after bringing his language into the world, Stroustrup
compared his earliest goals to how the language has ultimately evolved,
shared some thoughts on the world’s other programming languages, and
revealed what he does when he’s not shepherding the language’s massive
user community. And he also took a few moments to explain why C++ “is
far, far better than it was a couple of decades ago.”"

Dadgum, we are all getting old.

Lynn

[Daniel P]

On Monday, August 3, 2020 at 2:38:10 PM UTC-4, Lynn McGuire wrote:
> "C++ Creator Bjarne Stroustrup Weighs in on Distributed Systems, Type
> Safety and Rust" by David Cassel
>
> https://thenewstack.io/c-creator-bjarne-stroustrup-weighs-in-on-distributed-systems-type-safety-and-rust/
>

"He's a walkin' contradiction, partly truth and partly fiction"

basic type safety? Nobody who was concerned with type safety would ever
have introduced a bool type silently convertible to/from int.

generics? Then why all those distinctly non-generic functions to_string()
to_wstring(), stoul, stoull, etc.?

"Takin' every wrong direction on his lonely way back home"

Daniel

[Manfred]

The video is interesting, IMO especially in the part where Bjarne talks
about some possible future in distributed computing, both with
non-shared memory and integration between different processors, like
CPUs and GPUs.
Having some solid support for this in the language could be quite
interesting.

[Chris Vine]

Not to mention gratuitously breaking valid C++11/14 code in C++17, for
no benefit which I am able to discern.

[Richard]

[Please do not mail me a copy of your followup]

Lynn,

I just want to say thanks for sharing these links. I try to read most
of them, have almost never heard of any of them :), and usually find
them worth my time.

Your contributions here make it worth spending the time to come back
to the newsgroup, IMO!
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Lynn McGuire]

On 8/4/2020 4:13 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Lynn,
>
> I just want to say thanks for sharing these links. I try to read most
> of them, have almost never heard of any of them :), and usually find
> them worth my time.
>
> Your contributions here make it worth spending the time to come back
> to the newsgroup, IMO!

You are welcome. I use C++ and F77 almost every day and like to share
mentions of them.

Lynn

[Chris M. Thomasson]

I think so.

[Tim Rentsch]

Daniel P <daniel...@gmail.com> writes:

> basic type safety? Nobody who was concerned with type safety
> would ever have introduced a bool type silently convertible
> to/from int.

Converting a boolean value to an integer value, or vice versa, is
perfectly type safe. One might consider it desirable, or not,
for a language to allow such conversions non-explicitly in some
situations, but there is no question that such conversions (as
C++ defines the respective value transformations) are type safe.

[daniel...@gmail.com]

On Sunday, August 23, 2020 at 6:01:46 AM UTC-4, Tim Rentsch wrote:

Wikipedia defines "type safety" as "the extent to which a programming
language discourages or prevents type errors". I think it would be
hard to argue that treating a bool as an integral type, with built-in
implicit conversions to numeric types, in any way discourages type
errors.

Daniel

[Ben Bacarisse]

"daniel...@gmail.com" <daniel...@gmail.com> writes:

> On Sunday, August 23, 2020 at 6:01:46 AM UTC-4, Tim Rentsch wrote:
>> Daniel P writes:
>>
>> > basic type safety? Nobody who was concerned with type safety
>> > would ever have introduced a bool type silently convertible
>> > to/from int.
>> Converting a boolean value to an integer value, or vice versa, is
>> perfectly type safe. One might consider it desirable, or not,
>> for a language to allow such conversions non-explicitly in some
>> situations, but there is no question that such conversions (as
>> C++ defines the respective value transformations) are type safe.
>
> Wikipedia defines "type safety" as "the extent to which a programming
> language discourages or prevents type errors".

The trouble is that is almost circular. Of course safety in a
programming language refers to preventing errors, so type safety is
about prevent type errors, but that does not say much about what a type
error really is.

There are some obvious ones. In BCPL one could write

x := 42;
x!10 := 0

(which is x = 42; x[10] = 42; in C and C++). That's likely to be a
serious error in anything but some very specialised code. But other
cases are less clear. Given

double d; int i;

both d = i and i = d are assignments with miss-matched types. Are they
both unsafe? Equally unsafe?

> I think it would be
> hard to argue that treating a bool as an integral type, with built-in
> implicit conversions to numeric types, in any way discourages type
> errors.

I would be prepared to have go! Could you argue that this it /is/ a
type error? Conversion between arithmetic types are very common. Are
they all detrimental to type safety?

--
Ben.

[Alf P. Steinbach]

It's probably a good idea to use a bool wrapper type for function
results, and in general,

and equally true, it's probably impossible to convince more than maybe
one or two programmers in the world to do that, because C and C++
programmers are as a whole extremely conservative.

A wrapper can go like this:

template< class T >
static constexpr bool is_bool_ = std::is_same_v<T, bool>;

template< class Truth_class >
struct Truth_values_
{
static const Truth_class yes;
static const Truth_class no;
};

class Truth:
public Truth_values_<Truth>
{
bool m_value;

public:
/// \brief Implicit conversion to `bool` (only).
///
/// Implicit conversion to `bool` because that's needed for
template args.
/// Restricted via SFINAE because overload resolution, want
predictability.
template<
class Result,
class = Enable_if_<is_bool_<Result>>
>
constexpr operator Result() const noexcept { return m_value; }

/// \brief Construction from `bool` (only).
///
/// Construction SFINAE-restricted to `bool` argument.
template<
class Arg,
class = Enable_if_<is_bool_<Arg>>
>
constexpr Truth( const Arg value ) noexcept: m_value( value ) {}
};

template< class Truth_class >
const Truth_class Truth_values_<Truth_class>::yes = true;

template< class Truth_class >
const Truth_class Truth_values_<Truth_class>::no = false;

constexpr inline auto is_true( const Truth value )
-> Truth
{ return value; }

constexpr inline auto is_false( const Truth value )
-> Truth
{ return not value; }

constexpr inline auto operator+( const Truth value )
-> int
{ return 0 + !!value; }

constexpr inline auto operator!=( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs != !!rhs; }

constexpr inline auto operator<=( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs <= !!rhs; }

constexpr inline auto operator<( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs < !!rhs; }

constexpr inline auto operator==( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs == !!rhs; }

constexpr inline auto operator>=( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs >= !!rhs; }

constexpr inline auto operator>( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs > !!rhs; }

<url:
https://github.com/alf-p-steinbach/cppx-core-language/blob/master/source/cppx-core-language/types/Truth.hpp>

---

There is a question here also:

is there a possibly better way to declare the `Truth::yes` and
`Truth::no` constants?

The above “templated constant” trick feels Just Wrong™, but it was
evidently the best I could come up with at the time when I wrote that.

- Alf

[James Kuyper]

On 8/24/20 12:10 PM, Ben Bacarisse wrote:
> "daniel...@gmail.com" <daniel...@gmail.com> writes:

...

>> Wikipedia defines "type safety" as "the extent to which a programming
>> language discourages or prevents type errors".
>
> The trouble is that is almost circular. Of course safety in a
> programming language refers to preventing errors, so type safety is
> about prevent type errors, but that does not say much about what a type
> error really is.
>
> There are some obvious ones. In BCPL one could write
>
> x := 42;
> x!10 := 0
>
> (which is x = 42; x[10] = 42; in C and C++). That's likely to be a
> serious error in anything but some very specialised code. But other
> cases are less clear. Given
>
> double d; int i;
>
> both d = i and i = d are assignments with miss-matched types. Are they
> both unsafe? Equally unsafe?

The integers are a subset of the real numbers, d = i is likely to put
into d a floating-point representation of exactly the same integer value
that was represented by i. If DBL_EPSILON*INT_MAX < 0, it's guaranteed
to do so.
i = d can overflow. However, if it doesn't, i will end up representing a
value that differs by no more than 1.0 from the value represented by d.

When you convert between boolean and arithmetic values, it's not even
meaningful to ask whether the result represents the same value as the
original - there's no overlap between the set {true, false} and the
integers..

>> I think it would be
>> hard to argue that treating a bool as an integral type, with built-in
>> implicit conversions to numeric types, in any way discourages type
>> errors.
>
> I would be prepared to have go! Could you argue that this it /is/ a
> type error? Conversion between arithmetic types are very common. Are
> they all detrimental to type safety?

The thing is, bool is an arithmetic type only by fiat. Conceptually,
true is no more of an arithmetic value than 'A' is, but C++ calls them
both arithmetic. A more type-safe version of C++ would require the use
of constructs such as

arithmetic_value != 0

and

boolean_value ? 1 : 0

to do the equivalent of C++'s implicit conversions.

[Ike Naar]

On 2020-08-24, James Kuyper <james...@alumni.caltech.edu> wrote:
> [...] If DBL_EPSILON*INT_MAX < 0, it's guaranteed to do so.

If both DBL_EPSILON and INT_MAX are positive, can their product ever be < 0 ?

[Öö Tiib]

He apparently meant < 1 not < 0.

[David Brown]

"Type safety", I would say, really means that the only conversions done
are those that you know have a well defined meaning. It is about
objects having clearly defined types that can be used in certain ways,
and the language making it difficult to use them in other ways. In the
BCPL example, the language is not type safe. I don't know BCPL, so I
don't know if it is because there is no distinction between types
"integer" and "array of integer", or because there is nothing stopping
you using an integer as though it were an array.

In this sense, conversions between bool and other integer types is
type-safe - the behaviour is clearly specified and it is an allowed
operation on the types.

But you can certainly argue that it is not a good operation to allow,
and that C++ would be a "safer" language (not "type safer") if these
operations were not allowed. There are good arguments for saying that
"bool" should not have been considered an arithmetic type, especially as
conversions from other types to bool do not work in the same way as
conversions to other integer types. (Of course it is too late to change
things now.)

People also use the term "type safety" to mean "using types to make code
safer" - with the aim that more kinds of error in code can be caught as
compile-time errors rather than found at run-time or in testing. That
is, of course, a laudable aim - and automatic conversions between bool
and other arithmetic types goes against that aim.

[Chris Vine]

On Tue, 25 Aug 2020 10:42:19 +0200
David Brown <david...@hesbynett.no> wrote:
> "Type safety", I would say, really means that the only conversions done
> are those that you know have a well defined meaning.

"Type safety" describes a quality rather than anything particularly
quantifiable and so is subject to opinion. Even so I wouldn't agree
with your suggested definition. Given the address of an object of type
T held by a pointer to T, conversion of that pointer to void*, so
suppressing all static type information in the compiler, has a well
defined meaning in C++ but I don't think anyone would say it was type
safe.

Expressions like "strictly typed" or "soundly typed" are somewhat
clearer in the computer science world. In a strictly typed/soundly
typed language, which C++ isn't, every object representation must
actually be of the type explicitly indicated by the programmer or
unambigously inferred by the compiler on type unification, or the
program will not compile. "Strongly typed" is somewhat vaguer.
Implicit conversion from integer to bool and vice versa is ill-advised,
as also is implicit conversion from wider integers to narrower integers
more generally, and would offend many people's views of strong typing
(including it appears Richard's).

Fully type-checked dynamically typed languages such as python or lisp
can also be said to be strongly typed.

[daniel...@gmail.com]

On Tuesday, August 25, 2020 at 4:42:28 AM UTC-4, David Brown wrote:
> "Type safety", I would say, really means that the only conversions done
> are those that you know have a well defined meaning.

> ...

> In this sense, conversions between bool and other integer types is
> type-safe - the behaviour is clearly specified and it is an allowed
> operation on the types.
>

I think that's too narrow considering the common use of the term,
for example, a Microsoft document has "type safety ... means that
every variable, function argument, and function return value is storing
an acceptable kind of data, and that operations that involve values
of different types "make sense" and don't cause data loss, incorrect
interpretation of bit patterns, or memory corruption."

> But you can certainly argue that it is not a good operation to allow,
> and that C++ would be a "safer" language (not "type safer") if these
> operations were not allowed. There are good arguments for saying that
> "bool" should not have been considered an arithmetic type, especially as
> conversions from other types to bool do not work in the same way as
> conversions to other integer types. (Of course it is too late to change
> things now.)
>

At the time bool entered the language, the rationale was compatibility
with and easy conversion of C and C++ usage patterns like

#define bool int
#define true 1
#define false 0

bool once = 0;
if (!once++) {}

"type safety" was a far lesser consideration.

Daniel

[James Kuyper]

Sorry - that was supposed to be 1, not 0.

[James Kuyper]

On 8/25/20 4:42 AM, David Brown wrote:
...

> "Type safety", I would say, really means that the only conversions done
> are those that you know have a well defined meaning.

I agree with Wikipedia's opening description of type safety "In computer
science, type safety is the extent to which a programming language
discourages or prevents type errors." An implicit conversion that allows
you to use the wrong type is NOT an example of a feature that makes a
language type safe, no matter how well-defined the conversion is.

[David Brown]

On 25/08/2020 13:54, Chris Vine wrote:
> On Tue, 25 Aug 2020 10:42:19 +0200
> David Brown <david...@hesbynett.no> wrote:
>> "Type safety", I would say, really means that the only conversions done
>> are those that you know have a well defined meaning.
>
> "Type safety" describes a quality rather than anything particularly
> quantifiable and so is subject to opinion.

Agreed.

> Even so I wouldn't agree
> with your suggested definition. Given the address of an object of type
> T held by a pointer to T, conversion of that pointer to void*, so
> suppressing all static type information in the compiler, has a well
> defined meaning in C++ but I don't think anyone would say it was type
> safe.

C++ is not an entirely type-safe language. Conversions of pointers like
this are a way to get around the type-safety features the language
provides. But generally these things are undefined behaviour if used to
break type safety. Converting a pointer to a different pointer type
(directly, via void*, via uintptr_t, etc.) can have a well-defined
meaning in itself. But use of the converted pointer is highly
restricted - there is often little you can do (in the sense of having
well-defined behaviour) other than convert it back again.

However, I was inaccurate in the way I described it. Often the
conversions between incompatible pointer types can have well-defined
meanings - it is the /use/ of those converted pointers that is not well
defined.

>
> Expressions like "strictly typed" or "soundly typed" are somewhat
> clearer in the computer science world. In a strictly typed/soundly
> typed language, which C++ isn't, every object representation must
> actually be of the type explicitly indicated by the programmer or
> unambigously inferred by the compiler on type unification, or the
> program will not compile. "Strongly typed" is somewhat vaguer.
> Implicit conversion from integer to bool and vice versa is ill-advised,
> as also is implicit conversion from wider integers to narrower integers
> more generally, and would offend many people's views of strong typing
> (including it appears Richard's).
> > Fully type-checked dynamically typed languages such as python or lisp
> can also be said to be strongly typed.
>

Yes.

(It often surprises people to hear Python described as strongly typed -
it's easy to make the mistake of thinking strongly typed implies
statically typed.)

[Tim Rentsch]

You're confusing type safety and type strictness. Note the
characterization from Robin Milner at the start of the Wikipedia
article on type safety:

Well-typed programs cannot "go wrong".

The phrase "go wrong" means operate in a way that the language in
question does not define, or what in C or C++ would be called
undefined behavior. Because the conversions from bool to int,
and vice versa, are well defined, they are type safe.

Type strictness is concerned with whether or not various type
conversions are advisable. Should we allow an integer value to
be supplied where a floating-point value is asked for? In C++
the answer is (at least mostly) yes. Some other languages don't
allow it. Interpreted languages often go to the other extreme.
In JavaScript it's okay to "add" (with a + operator) a string
and an integer - the integer is converted to a string and
appended. JavaScript is type safe, by virtue of being checked
at runtime, but not especially (if at all) strictly typed.

For the most part C++ is not very strict in its type rules. If
an operation can be done, needing only reasonably plausible
conversions and without risking undefined behavior, then usually
it is allowed. When there is a risk of undefined behavior in
such cases then usually (though perhaps not always) a cast is
required to make the unsafe conversion explicit.

Lately (and I'm not sure what the time span is here) C++ has been
moving in the direction of being more strict in its type rules,
at least selectively. For example, in this code

enum E1 : int;
enum struct ES1 : int;

int
choose_nonzero( E1 e, ES1 es ){
if( e ) return e;
return es;
}

the conversion of type E1 to int (and also to bool) is allowed,
whereas the conversion of the type ES1 to int is disallowed. The
conversion of type ES1 to an int is safe: there is no risk of
undefined behavior. But the programmer has decided that such
conversions are not advisable, and so has chosen 'enum struct'
rather than a plain enum, taking advantage of a C++ feature to
provide more strictly typed constructions when they are thought
appropriate.

[Tim Rentsch]

Some further comments regarding these terminology questions.

Like what I said earlier, the description above is reversed with
respect to "strictly typed" and "type safe". "Type safe" is about
whether something is well defined (like what the earlier statement
from David Brown says). "Strictly typed" is about how liberal or
restrictive the typing rules are. Whether an operation (or
language) is type safe is an objective condition: if undefined
behavior can arise it is not safe, and conversely. In contrast,
whether an operation (or language) is strictly typed is a
subjective condition: some developers may find a certain type
rule overly restrictive, whereas others may find the same rule not
restrictive enough. Some languages, including C++, provide more
than one way of defining similar types, with the different ways
having different degrees of type strictness.

The word "sound" comes from mathematical logic. A logic is
/sound/ if it is consistent. It is important for the rules of a
language and its type logic to be sound, as otherwise nonsensical
results could be derived.

The terms "strong typing" and "strongly typed" unfortunately have
become little more than marketing phrases. I think the original
idea (ie, from the Liskov and Zilles paper) was that "strongly
typed" would mean something like what type safe means today.
However, the terms were co-opted by virtue of being used the DoD
requirements documents Steelman, Ironman, etc (and eventually
leading to Ada), to mean something closer to having restrictive
typing rules, which is to say more along the lines of being
strictly typed. The meaning of the terms was diluted to the
point where these days it can mean whatever an author wants it to
mean. A good meta-rule is this: if a language description says
the language is "strongly typed" but doesn't define the term,
there is a good chance that the term is pretty much meaningless.
A sad state of affairs, but empirically it seems to apply more
often than it doesn't.