On 07.03.2018 15:08, Paolo Invernizzi wrote:
> On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote:
>> On Wednesday, March 07, 2018 13:24:19 Paolo Invernizzi via Digitalmars-d wrote:
>>> [...]
>>
>> That would make assertions a lot worse to use, because then they would be in production code slowing it down. Also, as it stands, -release is not supposed to violate @safe. To do that, you have to use -boundscheck=off to turn off bounsd checking. That was a very purposeful design decision, because we did not want -release to violate @safe, and if the compiler is allowed to add optimizations which are unsafe based on assertions, then that completely destroys the ability to have @safe code with -release. And if we were going to do that, why did we leave array bounds checking on with -release?
>>
>> [...]
> 
> Jonathan, I understand your point, but still I can't find an answer to clarify my doubts.
> 
> Are we asking for no UB in @safe code?
> Are we asking for UB in @safe code but constrained to no memory corruptions?
> 
> /Paolo

UB is unconstrained by definition. If it is constrained, it is not UB.

On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote:
> On 07.03.2018 15:08, Paolo Invernizzi wrote:
>> On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote:
>>> [...]
>> 
>> Jonathan, I understand your point, but still I can't find an answer to clarify my doubts.
>> 
>> Are we asking for no UB in @safe code?
>> Are we asking for UB in @safe code but constrained to no memory corruptions?
>> 
>> /Paolo
>
> UB is unconstrained by definition. If it is constrained, it is not UB.

That! Thanks!

So, @safe code is code where UB should not be possible?
Is it pragmatically possible to reach that goal?

/Paolo

On 07.03.2018 16:30, Paolo Invernizzi wrote:
> On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote:
>> On 07.03.2018 15:08, Paolo Invernizzi wrote:
>>> On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote:
>>>> [...]
>>>
>>> Jonathan, I understand your point, but still I can't find an answer to clarify my doubts.
>>>
>>> Are we asking for no UB in @safe code?
>>> Are we asking for UB in @safe code but constrained to no memory corruptions?
>>>
>>> /Paolo
>>
>> UB is unconstrained by definition. If it is constrained, it is not UB.
> 
> That! Thanks!
> 
> So, @safe code is code where UB should not be possible?

Yes. (If you have UB, memory corruption is one of the allowed outcomes, but @safe should not allow memory corruption. So @safe needs to at least ban UB. According to Walter @safe needs to ban memory corruption but not more. Therefore, as memory corruption leads to UB (it is impractical to specify anything else, at least for writes), @safe bans UB and nothing else.)

Also note that even in @system code I don't want asserts to cause UB in release. There should be an @system facility for this purpose. (The situation is different than with bounds checks: if bounds checks fail, there will always be a bad memory access, which is UB, but with asserts it's always possible that the assert itself was wrong and the code itself will not trigger UB.)

> Is it pragmatically possible to reach that goal?
> 
> /Paolo

Yes. (Languages can be type safe and type systems can be arbitrarily powerful.) It is certainly possible to _aim_ for that goal, which Walter and Andrei have done on other occasions.

On Wednesday, 7 March 2018 at 16:04:50 UTC, Timon Gehr wrote:
> On 07.03.2018 16:30, Paolo Invernizzi wrote:
>> On Wednesday, 7 March 2018 at 15:26:01 UTC, Timon Gehr wrote:
>>> On 07.03.2018 15:08, Paolo Invernizzi wrote:
>>>> On Wednesday, 7 March 2018 at 13:55:11 UTC, Jonathan M Davis wrote:
>>>>> [...]
>>>>
>>>> Jonathan, I understand your point, but still I can't find an answer to clarify my doubts.
>>>>
>>>> Are we asking for no UB in @safe code?
>>>> Are we asking for UB in @safe code but constrained to no memory corruptions?
>>>>
>>>> /Paolo
>>>
>>> UB is unconstrained by definition. If it is constrained, it is not UB.
>> 
>> That! Thanks!
>> 
>> So, @safe code is code where UB should not be possible?
>
> Yes. (If you have UB, memory corruption is one of the allowed outcomes, but @safe should not allow memory corruption. So @safe needs to at least ban UB. According to Walter @safe needs to ban memory corruption but not more. Therefore, as memory corruption leads to UB (it is impractical to specify anything else, at least for writes), @safe bans UB and nothing else.)
>
> Also note that even in @system code I don't want asserts to cause UB in release. There should be an @system facility for this purpose. (The situation is different than with bounds checks: if bounds checks fail, there will always be a bad memory access, which is UB, but with asserts it's always possible that the assert itself was wrong and the code itself will not trigger UB.)
>
>> Is it pragmatically possible to reach that goal?
>> 
>> /Paolo
>
> Yes. (Languages can be type safe and type systems can be arbitrarily powerful.) It is certainly possible to _aim_ for that goal, which Walter and Andrei have done on other occasions.

Thanks Timon, now everything it's definitely more clear to me on that matter.

I think a good compromise is to just totally ignore assert in release during optimization as a default, and use a compiler flag to let the optimiser peek to them, if a user want to explore that potential gain.

Just like '-boundscheck'.

Thanks to all for having clarified that point to me (and hopefully to others also!)

/Paolo

On Tuesday, 6 March 2018 at 10:17:42 UTC, Walter Bright wrote:
> On 3/6/2018 1:58 AM, Jonathan M Davis wrote:
>> [...]
>
> The entire point of making assert a core language feature was so that the compiler could take advantage of it to generate better code. It's been like that for D since day 1. It has always been documented to do that. It has been discussed many times in this n.g. over the years with loooong threads. I designed it that way so that D could potentially produce better code than other languages in ways they could not match.
>
> There is no other purpose to making it a core language feature.
>
> It's fine if you want an assert-like feature to have other semantics - just define one called 'check', give it the semantics you want, and put it in the library. As I mentioned to Timon, support for that sort of thing is why D has special support for __LINE__ and __FILE__.

As a side node, we have a `verify()` exactly for this:
https://github.com/sociomantic-tsunami/ocean/blob/v3.x.x/src/ocean/core/Verify.d

(and because in some circumstances we need to be able to catch programming errors in servers that are low risk to catch and just ignore the current request and continue with our lives, with asserts we can't do that because they throw an Error).