On Wed, 13 Jul 2016 10:25:55 +0000, sarn wrote:
> Implementation-defined stuff is something that's not specified, but can be presumed to do *something*.  Undefined stuff is something that's officially considered to not even make sense

This comes from the C++ spec. We're following the same definitions. To wit:

"""
The semantic descriptions in this International Standard define a
parameterized nondeterministic abstract machine.

Certain aspects and operations of the abstract machine are described in this International Standard as implementation-defined (for example, sizeof (int)). These constitute the parameters of the abstract machine. Each implementation shall include documentation describing its characteristics and behavior in these respects.

Certain other aspects and operations of the abstract machine are described in this International Standard as unspecified (for example, order of evaluation of arguments to a function). Where possible, this International Standard defines a set of allowable behaviors. These define the nondeterministic aspects of the abstract machine.

Certain other operations are described in this International Standard as
undefined (for example, the effect of dereferencing the null pointer).
[ Note: this International Standard imposes no requirements on the
behavior of programs that contain undefined behavior. —end note ]
"""

Implementation-defined stuff *is* specified. It's specified in the documentation of each compiler.

Undefined stuff *can* make sense. I want to mutate a data structure marked immutable. It's obvious what I want to have happen, it's just not obvious what will actually happen.

On 13/07/16 14:28, Andrei Alexandrescu wrote:
>
> Interesting distinction. We must render the latter undefined but not the
> former. Consider:

Here's the definition I'm proposing:
It is undefined behavior to cast away immutable, const or shared modifiers and reference the memory if any other part of the program accesses that memory with the modifiers intact.

Examples of behavior that is not undefined:
Affix allocator: Accesses memory that is always accessed as mutable
Intrusive reference counting inside a struct: same deal
Only casting a pointer: no access

Shachar

On Wednesday, 13 July 2016 at 13:52:06 UTC, Chris Wright wrote:
> Undefined stuff *can* make sense. I want to mutate a data structure marked immutable. It's obvious what I want to have happen, it's just not obvious what will actually happen.

But the compiler is part of the abstract machine so it could simply refuse to compile a program that isn't valid, or it could define an extension that makes more programs valid.

One usually use the these terms:

«well-formed program»: a program that follows both the syntactical rules and the required statically-detected semantic rules.

«valid program»: a program that is well-formed and that also does not lead to semantic errors that are required to be detected at least at runtime (or in the case of undefined behaviour; errors that are not required to be detected for performance reasons).

Since C/C++ is aiming at avoiding semantic run-time checks the standard go with undefined behaviour instead. But there are compilers that do more than that.

On Tuesday, 12 July 2016 at 13:13:42 UTC, John Colvin wrote:
> This is so, so wrong. There's a world of difference between "you have to get this right or you're in trouble" and "the compiler (and especially the optimiser) is free to assume that what you're doing never happens".

I'd say the compiler (and especially the optimiser) should assume that mutable and immutable data don't overlap as if casting never happens. Not sure if this means gcc-style UB.

On Tuesday, 12 July 2016 at 18:37:20 UTC, deadalnix wrote:
> The thread was about complexity in the language. My point is that the current way things are done introduce a lot of accidental complexity, which is overall undesirable. This impact negatively various aspects of the languages, including, but not limited to, @safe .
>
> The problem I'm pointing at is that problems are considered in isolation, with disregard to the big picture. Ironically, this is exactly what is happening here, by debating every example to death rather than on the point.

Software design is an iterative process because one can't sort everything at once. Recommended read: https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/

On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote:
> On Tuesday, 12 July 2016 at 18:37:20 UTC, deadalnix wrote:
>
> Software design is an iterative process because one can't sort everything at once. Recommended read: https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/

If you look at the reviews that have less than four stars, the book doesn't seem to be very useful for people who are not beginners.

On Thursday, 14 July 2016 at 09:44:15 UTC, Chris wrote:
> If you look at the reviews that have less than four stars, the book doesn't seem to be very useful for people who are not beginners.

I meant high-level knowledge about software design in chapter 5.

On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote:

> Software design is an iterative process because one can't sort everything at once.

Not true. Ola can. :) (I just couldn't resist ...)

On Thursday, 14 July 2016 at 11:38:59 UTC, Chris wrote:
> On Wednesday, 13 July 2016 at 17:30:53 UTC, Kagamin wrote:
>
>> Software design is an iterative process because one can't sort everything at once.
>
> Not true. Ola can. :) (I just couldn't resist ...)

I don't have time for a long rant on this... But if you are designing a truly new langauge  (and D isn't), then you create prototypes, then you build a framework that is suitable for evolutionary design, then you spec it, then you try to prove it sound, then you implement it then you trash it, and redesign it and write a new spec. Once you have a foundation where most things can be expressed in libraries you have a good base for iterating and handing it to the world.

Of course, the first thing you ought to do is to look at existing knowhow related to language design.

That's a no-brainer.

The alternative, to just iterate, is what gives you languages like Perl and Php.

On Thursday, 14 July 2016 at 12:12:34 UTC, Ola Fosheim Grøstad wrote:
> I don't have time for a long rant on this... But if you are designing a truly new langauge  (and D isn't), then you create prototypes, then you build a framework that is suitable for evolutionary design, then you spec it, then you try to prove it sound, then you implement it then you trash it, and redesign it and write a new spec.

What's the reason to implement what can't work even for you alone?