On Thursday, 24 February 2022 at 19:14:39 UTC, Walter Bright wrote:
>
> I agree, which makes this a challenge.
>
> One solution is to design the return value so that failure is a valid part of the type. For example, searching for X can return an empty result, rather than a special "not found" error.
>
> Another solution is to redesign the problem. For example, currently Phobos throws on an invalid Unicode character. A better way is to treat such as a "replacement character".

Since you want to go that route and it might be applicable and convenient for some interfaces, you should consider adding a nullable type i D, and a language native nullable not only a library template type. You cannot find a "magic value" for all interfaces and a nullable type would solve that.

I would like that D outright copies the C# syntax for the nullable type (because I like it). The '?' makes it easy to implement and encourage people to use it.

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-value-types

D has so many similarities with C# by now, adding a C# nullable syntax wouldn't hurt. D could even win over some C# people when they need compiled code or for whatever reason. When they see that D looks almost like C#, they rather stick with D than "modern C++".

On Wednesday, 2 March 2022 at 00:03:48 UTC, IGotD- wrote:
> On Thursday, 24 February 2022 at 19:14:39 UTC, Walter Bright wrote:
>>
>> I agree, which makes this a challenge.
>>
>> One solution is to design the return value so that failure is a valid part of the type. For example, searching for X can return an empty result, rather than a special "not found" error.
>>
>> Another solution is to redesign the problem. For example, currently Phobos throws on an invalid Unicode character. A better way is to treat such as a "replacement character".
>
> Since you want to go that route and it might be applicable and convenient for some interfaces, you should consider adding a nullable type i D, and a language native nullable not only a library template type. You cannot find a "magic value" for all interfaces and a nullable type would solve that.
>
> I would like that D outright copies the C# syntax for the nullable type (because I like it). The '?' makes it easy to implement and encourage people to use it.
>
> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-value-types
>
> D has so many similarities with C# by now, adding a C# nullable syntax wouldn't hurt. D could even win over some C# people when they need compiled code or for whatever reason. When they see that D looks almost like C#, they rather stick with D than "modern C++".

Yeah, I got to D from C#, granted it was like a decade ago, so C# was still missing a lot of the modern features like built-in tuples, method shortened syntax, async/await was barely a thing (I believe it was started to be introduced.) and so on. However I still program in C# and once in a while there are some features I miss when I go back to D, it used to be the other way around.

On Wednesday, 2 March 2022 at 00:03:48 UTC, IGotD- wrote:
> On Thursday, 24 February 2022 at 19:14:39 UTC, Walter Bright wrote:
>>
>> I agree, which makes this a challenge.
>>
>> One solution is to design the return value so that failure is a valid part of the type. For example, searching for X can return an empty result, rather than a special "not found" error.
>>
>> Another solution is to redesign the problem. For example, currently Phobos throws on an invalid Unicode character. A better way is to treat such as a "replacement character".
>
> Since you want to go that route and it might be applicable and convenient for some interfaces, you should consider adding a nullable type i D, and a language native nullable not only a library template type. You cannot find a "magic value" for all interfaces and a nullable type would solve that.
>
> I would like that D outright copies the C# syntax for the nullable type (because I like it). The '?' makes it easy to implement and encourage people to use it.
>
> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/nullable-value-types
>
> D has so many similarities with C# by now, adding a C# nullable syntax wouldn't hurt. D could even win over some C# people when they need compiled code or for whatever reason. When they see that D looks almost like C#, they rather stick with D than "modern C++".

That's indeed a nice way to represent nullable/optional, I personally prefer calling such feature as "optional", null is already a thing when playing with pointers, that'd cause confusion to call it nullable imo

On Friday, 25 February 2022 at 00:30:49 UTC, H. S. Teoh wrote:
> On Thu, Feb 24, 2022 at 11:59:56PM +0000, meta via Digitalmars-d wrote: [...]
>> Nobody said to verbatim copy what C does, I personally explicitly said to take that idea and evolve it, just like the newer modern languages are properly doing (Go, Zig, Rust, Odin)
>
> Go, Zig, Rust, and Odin all require explicit checking for error returns.

Nope: http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/reference/expressions/operator-expr.html#the-question-mark-operator

Years ago, I justified my preference for exceptions because the rest of the call stack didn't have to be cluttered with "rethrowing". Having to pattern match is better, but still a pain. The macro solution they went with is the only one I know of that is as easy to use as exceptions without the associated baggage.

Atila

On 04/03/2022 1:05 AM, Atila Neves wrote:
>> Go, Zig, Rust, and Odin all require explicit checking for error returns.
> 
> Nope: http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/reference/expressions/operator-expr.html#the-question-mark-operator 
> 
> 
> Years ago, I justified my preference for exceptions because the rest of the call stack didn't have to be cluttered with "rethrowing". Having to pattern match is better, but still a pain. The macro solution they went with is the only one I know of that is as easy to use as exceptions without the associated baggage.

We could do something like this, with both isNull methods and a value type exception. We just need this extra form of catch statement.

Could be a pretty good simple addition to whatever DIP is put forward.

```diff
Catch:
+	"catch" NoScopeNonEmptyStatement
```

On Thursday, 3 March 2022 at 12:05:11 UTC, Atila Neves wrote:
> On Friday, 25 February 2022 at 00:30:49 UTC, H. S. Teoh wrote:
>>
>> Go, Zig, Rust, and Odin all require explicit checking for error returns.
>
> Nope: http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/reference/expressions/operator-expr.html#the-question-mark-operator
>
> Years ago, I justified my preference for exceptions because the rest of the call stack didn't have to be cluttered with "rethrowing". Having to pattern match is better, but still a pain. The macro solution they went with is the only one I know of that is as easy to use as exceptions without the associated baggage.

Swift has similar syntax sugar with its "try" keyword:

https://docs.swift.org/swift-book/LanguageGuide/ErrorHandling.html

And of course there are also more general-purpose language features like Haskell's "do" notation [1] and Scala's "for" comprehensions [2] that handle this as a special case.

[1] https://en.m.wikibooks.org/wiki/Haskell/do_notation
[2] https://docs.scala-lang.org/tour/for-comprehensions.html

On Thursday, 3 March 2022 at 12:19:44 UTC, rikki cattermole wrote:
>
> We could do something like this, with both isNull methods and a value type exception. We just need this extra form of catch statement.
>
> Could be a pretty good simple addition to whatever DIP is put forward.
>
> ```diff
> Catch:
> +	"catch" NoScopeNonEmptyStatement
> ```

How is it with value type exceptions, would they need typeinfo as well? If it needs typeinfo, then it wouldn't work with better C. Actually I would rather omitting typeinfo to be a separate compiler switch as typeinfo is such a useful feature you should be able to pick if you need it or not.

For those embedded systems that have no space for typeinfo, then I'd say that value type exception shouldn't work. In those systems you probably want full control and your own error handling anyway. For embedded system that has a bit more room, then value type exceptions together with typeinfo is a good compromise.

On 04/03/2022 4:43 AM, IGotD- wrote:
> How is it with value type exceptions, would they need typeinfo as well? If it needs typeinfo, then it wouldn't work with better C. Actually I would rather omitting typeinfo to be a separate compiler switch as typeinfo is such a useful feature you should be able to pick if you need it or not.

They are structs, no TypeInfo required (although the compiler should be free to promote class based exceptions to value type as long as the user would not notice it).