On 12/30/2022 3:47 PM, areYouSureAboutThat wrote:
> Why would anyone would store their passwords in the cloud? What were they thinking!?!?

Google is always popping up offering to store my passwords for me. Not a chance of that happening.

On 12/30/2022 4:24 PM, H. S. Teoh wrote:
> 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".

You guys should be pleased I didn't add "blockchain" to the list of D's features.

But wait a minute - maybe I should?

On Saturday, 31 December 2022 at 01:45:06 UTC, Walter Bright wrote:
> But hey, this discussion is ultimately pointless. D will get sumtypes

Object and int* and friends are already sumtypes.

They are

sumtype {
   typeof(null),
   actual Object/int*/whatever
}


But the compiler doesn't really realize this.

On 12/31/22 02:45, Walter Bright wrote:
>>
>> 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.
> ...

Well, he said "e.g.". It's perfectly reasonable to design the language such that people can opt into the free hardware check. Ultimately those are implementation details.

> ...
> ----
> 
> 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!

So far my understanding is that you are aiming for:
- keep references/pointers with implicit null values
- add references/pointers with explicit null values

What's still potentially missing:
- references/pointers without any null values (fundamentally at odds with T.init, this is why I brought this up in the first place)
- static checking

On 12/31/22 02:50, Walter Bright wrote:
> On 12/30/2022 4:24 PM, H. S. Teoh wrote:
>> 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".
> 
> You guys should be pleased I didn't add "blockchain" to the list of D's features.
> 
> But wait a minute - maybe I should?
> 

It's called `pure`, but D falls a bit short of the ideal. Nondeterministic semantics of `pure` functions are fatal for blockchain applications.

On Saturday, 31 December 2022 at 01:50:34 UTC, Walter Bright wrote:
> On 12/30/2022 4:24 PM, H. S. Teoh wrote:
>> 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".
>
> You guys should be pleased I didn't add "blockchain" to the list of D's features.
>
> But wait a minute - maybe I should?

https://github.com/zhuowei/nft_ptr This but for the GC

On 12/30/2022 1:07 PM, Timon Gehr wrote:
>> In your description of pattern matching checks in this thread, the check was at runtime.
>> ...
> 
> No, the check was at compile time.

The pattern matching is done at run 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.
NonNull pointers:

  int* p = ...;
  nonnull int* np = isPtrNull(p) ? fatalError("it's null!") : p;
  *np = 3; // guaranteed not to fail!

Null pointers:

  int* p = ...;
  *p = 3;  // seg fault!

Which is better? Both cause the program to quit on a null pointer.


> This technology has a proven track record.

A proven track record of not seg faulting, sure. A proven trackrecord of no fatal errors at converting a nullable pointer to nonnull, I'm not so sure.


> Relying on hardware memory protection to catch the null
> reference is never necessary,

If you manually code in a runtime check, sure, you won't need a builtin check at runtime.

> because _valid programs should not even compile if
> that's the kind of runtime check they would require to ensure type safety_.

Then we don't need sumtypes with pattern matching?

> The hardware memory protection can still catch compiler bugs I guess.

Having a hardware check is perfectly valid for checking things.

BTW, back in the bad old DOS days, I used to write a lot of:

    assert(p != NULL);

It was very effective. But with modern CPUs, this check adds no value, and I removed them.

On Saturday, 31 December 2022 at 02:15:43 UTC, Timon Gehr wrote:
> What's still potentially missing:
> - references/pointers without any null values (fundamentally at odds with T.init, this is why I brought this up in the first place)
> - static checking

Non-null pointers would be a major step forward. Don't know how they will fit in with the rest, but I would use them all the time.

As for null, note that in WASM it is a valid address.

On Saturday, 31 December 2022 at 06:34:38 UTC, Walter Bright wrote:
> NonNull pointers:
>
>   int* p = ...;
>   nonnull int* np = isPtrNull(p) ? fatalError("it's null!") : p;
>   *np = 3; // guaranteed not to fail!
>
> Null pointers:
>
>   int* p = ...;
>   *p = 3;  // seg fault!
>
> Which is better? Both cause the program to quit on a null pointer.

In a larger program the first one allows the programmer to do the check once and rely on it for the remainder of the program.

Essentially it leverages the type system to make invalid state unrepresentable. This simplifies subsequent code.

It is very much similar to representing a phonenumber using either a string or a dedicated phonenumber type. The way you construct an instance of the phonenumber type is through a check, and any function accepting it can rely on it. In contrast, if one uses strings to pass around phonenumbers, you will need so many checks everywhere you likely forget one.

>
> Having a hardware check is perfectly valid for checking things.
>

Not all targets have said check though.