On 12/29/2022 7:37 PM, Timon Gehr wrote:
> I am not saying software can't be allowed to fail, just that it should fail compilation, not at runtime.

In your description of pattern matching checks in this thread, the check was at runtime.

(Of course, we'd all like the compiler to detect all the errors at compile time. D does an awful lot of that.)

What I meant was default construction, which is not necessary in D. Constructors are still allowed for non-default construction.

On 12/30/22 21:27, Walter Bright wrote:
> On 12/29/2022 8:01 PM, Timon Gehr wrote:
>  > Even array bounds overflow exceptions would be better as compile-time errors. If you don't consider that practical, that's fine, I guess it will take a couple of decades before people accept that this is a good idea,
> 
> The size of the array depends on the environment. I don't see how to do that at compile time.
> ...

Well, it can be done in many cases. The point is it would be even better. I made this point because you said a null pointer segfault is like a bounds-checking failure. I agree.

>  > but it's certainly practical today for null dereferences.
> 
> Pattern matching inserts an explicit runtime check, rather than using the hardware memory protection to do the check. All you get with pattern matching is (probably) a better error message, and a slower program. You still get a fatal error, if the pattern match arm for the null pointer is fatal.
> ...

If the pattern match arm for the null pointer is fatal, maybe the reference should not have been typed as nullable in the first place, and no check should have been required at all. You seem to be reasoning from the position that the fatal runtime error was unavoidable. This is just not the case I care about at all.

> You can also get a better error message with a seg fault if you code a trap for that error.
> 
> Isn't it great that the hardware provides runtime null checking for you at zero cost?
> ...

I am saying A > B, you are saying B > C. I agree that B > C. I don't know what to tell you.

> If a seg fault resulted in memory corruption, then I agree with you. But it doesn't, it's at zero cost, your program runs at full speed.
> ...

Errors manifesting in production that should have been caught immediately at compile time are not zero cost. Not even close.

E.g., see https://deepsource.io/blog/exponential-cost-of-fixing-bugs/

Sometimes, the original developer is not even around anymore and/or does not care to fix crashes. The cost to users can be very high, and at the very least it is embarrassing to the developer.

> P.S. in the bad old DOS days, a null pointer write would scramble DOS's interrupt table, which had unpredictable and often terrible effects. Fortunately, uP's have evolved since then into having hardware memory protection, so that is no longer an issue. As soon as I got a machine with memory protection, I switched all my development to that. Only as a last step did I recompile it for DOS.
> 

So your point is that B > C, therefore you switched from C to B.

My point is that A > B, so I want to switch from B to A.

Unfortunately, there's some nontrivial cost to jumping ship and switching languages, so I am engaging in this kind of seemingly fruitless discussion instead.

On 12/30/22 21:41, Walter Bright wrote:
> On 12/29/2022 7:37 PM, Timon Gehr wrote:
>> I am not saying software can't be allowed to fail, just that it should fail compilation, not at runtime.
> 
> In your description of pattern matching checks in this thread, the check was at runtime.
> ...

No, the check was at compile time. The check I care about is the check for _failure_. The check for _null_ may or may not be _necessary_ depending on the type of the reference. Relying on hardware memory protection to catch the null reference is never necessary, because _valid programs should not even compile if that's the kind of runtime check they would require to ensure type safety_. The hardware memory protection can still catch compiler bugs I guess.

> (Of course, we'd all like the compiler to detect all the errors at compile time. D does an awful lot of that.)
> 

Well, glad we are on the same page at least. But what is the concern then? This technology has a proven track record.

On 12/30/22 21:27, Walter Bright wrote:
> 
> Pattern matching inserts an explicit runtime check, rather than using the hardware memory protection to do the check.

If the program crashes in case a reference is null, there is a bug in the logic of the program. If I fix that bug, the hardware memory protection will no longer be the one that's responsible for the check, just like for pattern matching. It will be explicit in the logic. I care about the correct program. Why would I care whether a crash costs me additional runtime? The check is either necessary or it is not necessary. If it is not necessary, even the hardware check is redundant, otherwise the hardware check does nothing that the compiler should not have caught even earlier.

On Friday, 30 December 2022 at 20:38:52 UTC, Walter Bright wrote:
> On 12/29/2022 7:04 PM, monkyyy wrote:
>> [...]
>
> Please reconsider your "every attempt" statement. It's a surefire way to disaster.
>
>
>> [...]
>
> Sorry, but again, that is attempting to write perfect software. It is *impossible* to do. Humans aren't capable of doing it, and from what I read about the space shuttle software is it is terrifyingly expensive to do all that checking and so it does not scale.
>
> The right way is not to imagine one can write perfect software. It is to have a plan for what to do *when* the software fails. Because it *will* fail.
>
> For example, a friend of mine years ago told me he was using a password manager for his hundreds of passwords to keep them safe. I told him it that the PWM is a single point of failure, and when it failed it would compromise all of his passwords. He dismissed the idea, saying he trusted the password manager company.
>
> Fast forward to today. LastPass, which is what he was relying on, failed. Now all his hundreds of passwords are compromised.

Yes, no matter how correct the software is, no matter how perfectly memory safe the programming langauge is, it all comes back to 'the unanticipated interactions' - which cannot be avoided if you live in our universe.

The fate of software is never just in the hands of the progrmammer.

On Friday, 30 December 2022 at 20:38:52 UTC, Walter Bright wrote:
>
> Fast forward to today. LastPass, which is what he was relying on, failed. Now all his hundreds of passwords are compromised.

After a decade as systems engineer, I changed career in 2014 after realising how foolish it was for all these companies (and gov agencies) wanting to take all their systems and data, and put them into the 'cloud'. I knew what was coming, didn't want to be the person they end up blaming, and decided I wanted no part of it.

Now, these companies (and gov agencies) (and many more too come) pay the price for their foolishness.. and so will their customers. And this will continue, indefinately.

The only system that cannot be hacked, is the system that is turned off.

Why would anyone would store their passwords in the cloud? What were they thinking!?!?

On Fri, Dec 30, 2022 at 11:47:32PM +0000, areYouSureAboutThat via Digitalmars-d wrote:
> On Friday, 30 December 2022 at 20:38:52 UTC, Walter Bright wrote:
> > 
> > Fast forward to today. LastPass, which is what he was relying on, failed. Now all his hundreds of passwords are compromised.
> 
> After a decade as systems engineer, I changed career in 2014 after realising how foolish it was for all these companies (and gov agencies) wanting to take all their systems and data, and put them into the 'cloud'. I knew what was coming, didn't want to be the person they end up blaming, and decided I wanted no part of it.

Finally, someone else that sees through the king's invisible clothes! In the old days you just had to somehow include the word "Java" somewhere in your product and everyone will flock to buy it -- regardless of whether it actually solved anything.  These days, "Java" has been replaced by "cloud".


> Now, these companies (and gov agencies) (and many more too come) pay
> the price for their foolishness.. and so will their customers. And
> this will continue, indefinately.
> 
> The only system that cannot be hacked, is the system that is turned off.

The only safe way to use the internet is not to use it. :-D


> Why would anyone would store their passwords in the cloud? What were they thinking!?!?

They weren't thinking. :-D


T

-- 
May you live all the days of your life. -- Jonathan Swift

On 12/30/2022 1:46 PM, Nick Treleaven wrote:
> What that buys you is a way to convert a nullable reference to non-nullable, without the possibility of an accidental fatal error.

At some point, you did insert a check. For example, if you have an array of file pointers, and want to remove one. Do you compact the array, or just leave a null entry? Leaving a null entry is faster, and if you forget to add a check, the hardware will check it for you.


> Plus sometimes whole program optimization can remove those checks. The compiler could potentially generate another version of a function taking a nullable parameter, one for a non-nullable reference. Any null path is statically removed in that version.

That's true. And for a null pointer, the null path is statically not there, even though the checking remains for free!


>> You still get a fatal error, if the pattern match arm for the null pointer is fatal.
> 
> If the arm for null is fatal then the programmer must have deliberately opted-in to a fatal error by typing e.g. `assert(0)`. Not accidentally forgetting to handle null, which is a common mistake.

Yes, that's exactly what I was talking about. You've substituted a free hardware check for a costly check.


> Unfortunately it's not 100% reliable. If you have a null reference to a type with fields whose offset is big enough to take it into a valid memory address, then that hardware check won't catch it.

Yes, you are correct. I think D has a limit on the size of a struct object for that reason.

----

But hey, this discussion is ultimately pointless. D will get sumtypes and pattern matching at some point. You can write code in your preferred style - no problem!