On Tuesday, 12 April 2022 at 22:23:18 UTC, ag0aep6g wrote:
> On Tuesday, 12 April 2022 at 19:54:13 UTC, wjoe wrote:
>> Especially since it's only a promise and the compiler accepts this:
>>
>> void foo (const(char)[] arr)
>> {
>>   cast(char[])arr[0..3] = "baz";
>> }
>> string bar = "123";
>> foo(bar);
>> assert(bar=="baz");
>>
>> But I could cast away const and modify the string bar.
>
> No, you could not. You're relying on undefined behavior there. Just because the compiler accepts something, doesn't mean it's ok.
>
> If you want to be guarded against wandering into undefined territory, that's what @safe does. With @safe, the cast doesn't compile.

Undefined behavior yes, but regardless the example proves it can be done in @system code.
A few versions ago, possibly due to a bug or regression, the compiler didn't complain in @safe code either.

Of course you are correct academically. However, since it's possible, I'd wager my last hat that code like this is out in the wild.

On Tuesday, 12 April 2022 at 23:23:59 UTC, Ali Çehreli wrote:
> [...]

Looking at this from a technical perspective - everything you say is true - and thanks for clearing up some of my confusion in that department.

Looking at this from a natural language (English) perspective - words prompt ideas and expectations. If these expectations aren't met confusion and misunderstanding happens (and that's not just true for software development).
Although, perhaps, that's only a problem for (some) non native English speakers ? The fact remains that there's confusion and misunderstandings regarding const, immutable and const 2.

On 14.04.22 13:42, wjoe wrote:
> Undefined behavior yes, but regardless the example proves it can be done in @system code.
> A few versions ago, possibly due to a bug or regression, the compiler didn't complain in @safe code either.
> 
> Of course you are correct academically. However, since it's possible, I'd wager my last hat that code like this is out in the wild.

No, it cannot be done in @system code. The example only proves that you can write nonsense code that has no defined meaning.

Note that the nonsense you wrote behaves as you describe only in Windows. Elsewhere, you get a segfault.

But it doesn't matter how the executable actually behaves. You cannot cite the result of undefined behavior when arguing language semantics.

On Thursday, 14 April 2022 at 12:10:04 UTC, ag0aep6g wrote:
> On 14.04.22 13:42, wjoe wrote:
>> Undefined behavior yes, but regardless the example proves it can be done in @system code.
>> A few versions ago, possibly due to a bug or regression, the compiler didn't complain in @safe code either.
>> 
>> Of course you are correct academically. However, since it's possible, I'd wager my last hat that code like this is out in the wild.
>
> No, it cannot be done in @system code. The example only proves that you can write nonsense code that has no defined meaning.
>
> Note that the nonsense you wrote behaves as you describe only in Windows. Elsewhere, you get a segfault.
>
> But it doesn't matter how the executable actually behaves. You cannot cite the result of undefined behavior when arguing language semantics.

Well I'm not using Windows so I wouldn't know but I compiled an ran that program on Linux and it didn't segfault. If it had I wouldn't have included that part in my reply.

On the matter of undefined behavior. Technically a program is in undefined behavior land after throwing an error, thus every unittest that continues after assertThrown is therefore nonsense code, is it not ?

On Sun, Apr 17, 2022 at 01:06:36PM +0000, wjoe via Digitalmars-d-learn wrote: [...]
> On the matter of undefined behavior. Technically a program is in undefined behavior land after throwing an error, thus every unittest that continues after assertThrown is therefore nonsense code, is it not ?

The spec explicitly makes an exception(!) in this case. See 10.24.11.3:

	https://dlang.org/spec/expression.html#assert_expressions

as well as 27.3:

	https://dlang.org/spec/unittest.html


T

-- 
An elephant: A mouse built to government specifications. -- Robert Heinlein

On 17.04.22 15:06, wjoe wrote:
> On the matter of undefined behavior. Technically a program is in undefined behavior land after throwing an error, thus every unittest that continues after assertThrown is therefore nonsense code, is it not ?

Yes.

Failing asserts are a messy part of the language. They are supposed to be:

1) not catchable, because they indicate a bug in the program;
2) catchable in order to be testable;
3) assumed impossible for optimization purposes.

Those goals are at odds with each other, and I don't think the spec manages to consolidate them.

But mutating `immutable` data is not messy. It's simply not allowed.

On Sun, Apr 17, 2022 at 04:09:12PM +0200, ag0aep6g via Digitalmars-d-learn wrote: [...]
> Failing asserts are a messy part of the language. They are supposed to be:
> 
> 1) not catchable, because they indicate a bug in the program;
> 2) catchable in order to be testable;
> 3) assumed impossible for optimization purposes.
> 
> Those goals are at odds with each other, and I don't think the spec manages to consolidate them.

Not entirely true. See paragraph 3 in:

	https://dlang.org/spec/unittest.html

and 10.24.11.3 in:

	https://dlang.org/spec/expression.html#assert_expressions


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy

On 17.04.22 15:27, H. S. Teoh wrote:
> On Sun, Apr 17, 2022 at 01:06:36PM +0000, wjoe via Digitalmars-d-learn wrote:
> [...]
>> On the matter of undefined behavior. Technically a program is in
>> undefined behavior land after throwing an error, thus every unittest
>> that continues after assertThrown is therefore nonsense code, is it
>> not ?
> 
> The spec explicitly makes an exception(!) in this case. See 10.24.11.3:
> 
> 	https://dlang.org/spec/expression.html#assert_expressions
> 
> as well as 27.3:
> 
> 	https://dlang.org/spec/unittest.html

But the failing assert is not part of the unittest directly. It's in a function that is called from the unittest. It takes a generous interpretation of the spec to include such asserts in the exception.

Letting failing asserts cause UB is a mistake anyway. It stems from a misguided desire to re-use asserts for optimization, when nobody actually uses them that way.

On Sunday, 17 April 2022 at 14:14:37 UTC, H. S. Teoh wrote:
> Not entirely true. See paragraph 3 in:
>
> 	https://dlang.org/spec/unittest.html
>
> and 10.24.11.3 in:
>
> 	https://dlang.org/spec/expression.html#assert_expressions
>
>
> T

Thanks. Either I missed that the last time I checked or it wasn't there ;)
But the interesting question is: does the compiler go out of its way to make that happen or is it just paragraphs written in the spec?

On Mon, Apr 18, 2022 at 12:55:26PM +0000, wjoe via Digitalmars-d-learn wrote:
> On Sunday, 17 April 2022 at 14:14:37 UTC, H. S. Teoh wrote:
> > Not entirely true. See paragraph 3 in:
> > 
> > 	https://dlang.org/spec/unittest.html
> > 
> > and 10.24.11.3 in:
> > 
> > 	https://dlang.org/spec/expression.html#assert_expressions
[...]
> Thanks. Either I missed that the last time I checked or it wasn't
> there ;)
> But the interesting question is: does the compiler go out of its way
> to make that happen or is it just paragraphs written in the spec?

My guess: the spec was amended after the fact. :-D


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N