dip1000 and preview in combine to cause extra safety errors

[Paulo Pinto]

On Thursday, 9 June 2022 at 00:34:51 UTC, forkit wrote:
> On Thursday, 9 June 2022 at 00:04:07 UTC, Mathias LANG wrote:
>>
>> `@safe` by default is only viable if `@safe` has minimum to no 
>> friction.
>> This isn't the case *at all*. We have examples in the standard 
>> library itself.
>>
>> It's also departing from D's identity as a system programming 
>> language which makes it trivial to interop with C / C++, 
>> alienating a sizeable portion of our community in the process.
>
> It does seem to me, that there is greater move towards memory 
> safety 'by default', and not away from it.
>
> Rust has demonstrated, that this is not antithetical to systems 
> programming.
>
> Unsafe is always available when it's required.
>
> But yes, certainly, @safe needs a lot more work for it to ever 
> be considered as a default in D. I have it as default in every 
> module I create. I usually have to end up commenting it out, 
> even for simple things.
>
> But IMO, in programming, one should be moving towards being 
> explicit about being unsafe, rather than being safe.
>
> Those who are truly alienated by such an idea, have C/C++ ;-)

Fun historical fact, the first languages to have unsafe code 
blocks date back to early 60's, late 50's, JOVIAL and ESPOL 
(superseded by NEWP). NEWP is still used in production, on 
ClearPath MCP mainframes sold by Unisys, and I wouldn't be 
surprised if US army wouldn't have some stuff running JOVIAL.