[OffTopic] A vulnerability postmortem on Network Security Services

[bachmeier]

On Friday, 3 December 2021 at 06:57:49 UTC, Tejas wrote:
> On Thursday, 2 December 2021 at 19:35:25 UTC, bachmeier wrote:
>> On Thursday, 2 December 2021 at 17:21:58 UTC, Tejas wrote:
>>> On Thursday, 2 December 2021 at 17:11:09 UTC, Paul Backus 
>>> wrote:
>>>> [...]
>>>
>>> Hmm... not a fan of that solution
>>>
>>> Still feel marking `extern (C)` stuff as `@trusted` is better.
>>>
>>> Introducing a new feature for such a fundamental, yet obvious 
>>> thing seems overkill, IMHO. Forcing not `@safe` stuff to be 
>>> annotated seems better to me.
>>
>> Sure, if you don't use extern(C) much and you don't care about 
>> everyone that uses it extensively in their code moving to 
>> other languages, go ahead and do that. It's not realistic to 
>> break that much code written in a language that was designed 
>> from the start to be closely tied to C. It wouldn't be hard to 
>> add a -safe compilation flag, but apparently nobody's into 
>> that, they'd prefer to break code others have written.
>
> I think the problem with adding new compiler flags is that it 
> doubles the amount of configs that have to be checked/tested 
> for from then on-wards (at least that's what I was told when I 
> asked if it was possible to do away with the `short/byte` 
> implicit conversion to `int` via a compiler flag).

I understand. It was during this conversation that I realized D 
has no strategy that will allow it to evolve (and no strategy to 
develop such a strategy). The cost of making an extreme change 
like safe by default is that you have to accept a compiler flag 
or some other compromise. That seems to be off the table, which 
makes it hard to see D being much different in 2041 than it is 
now.