On 2020-11-01 03:14, Ola Fosheim Grøstad wrote:

> I can see why someone would think Zig is inspired by Jai, though. Zig appears to focus on not having any "magic", so that the source is explicit. Not a reasonable design rationale IMO. Properties and exceptions are useful abstractions.

I don't think exceptions need to go against being explicit in the source code. It just happens that's how most languages implement them. For example, requiring functions that can throw an exception, to be annotated (with the exceptions it can throw). And require all those functions to be called with a specific syntax solves that.

If you look at how Zig (same with Swift) implements error handling, you see that it's very similar to how exceptions work. At least from a source code point of view. Then the implementation is completely different under the hood.

-- 
/Jacob Carlborg

On Sunday, 1 November 2020 at 13:58:57 UTC, Jacob Carlborg wrote:
> If you look at how Zig (same with Swift) implements error handling, you see that it's very similar to how exceptions work. At least from a source code point of view. Then the implementation is completely different under the hood.

I haven't used Zig, but as far as I can tell you have to test right after the function call? Swift is somewhat more tedious than regular exceptions... But not too bad.

On Sunday, 1 November 2020 at 16:34:49 UTC, Ola Fosheim Grøstad wrote:

> I haven't used Zig, but as far as I can tell you have to test right after the function call?

Actually, I thought that as well. But I just tried it and you don't have to call a function which can return an error with `try`. If you don't, then you just get back an error union (a type which consist of the return type and the error type). Then you can treat it like any other value. But it's not exactly like with exceptions.

--
/Jacob Carlborg

I've written a Java compiler, too.

If you're saying C++ did CTFE before D, bring it on. Show us!

On 11/1/2020 12:46 AM, Max Samukha wrote:
> How is that relevant? There are natively compiled Lisps. Also, to compile D at runtime, you need a D compiler as part of the runtime environment. If you insist on singling out one language that popularized CTFE, Lisp would be a much fairer choice.

It's been said that eventually all languages tend to adopt all the features of Lisp. But that doesn't mean that Lisp popularized those features. After all, Lisp is one of the original programming languages, and if it popularized CTFE then C, C++, Pascal, etc., would have had it long ago.

On Tuesday, 3 November 2020 at 05:26:51 UTC, Walter Bright wrote:
> On 11/1/2020 12:46 AM, Max Samukha wrote:
>> How is that relevant? There are natively compiled Lisps. Also, to compile D at runtime, you need a D compiler as part of the runtime environment. If you insist on singling out one language that popularized CTFE, Lisp would be a much fairer choice.
>
> It's been said that eventually all languages tend to adopt all the features of Lisp. But that doesn't mean that Lisp popularized those features. After all, Lisp is one of the original programming languages, and if it popularized CTFE then C, C++, Pascal, etc., would have had it long ago.

Well CTFE in my opinion is mostly useful as part of metaprogramming and code-generation so this explains the case of Pascal (and its modern derivatives). It does not need CTFE because it cannot do compile-time introspection, which is one of the pillar of metaprog I'd say (other pillars are template, CTFE).

Without CT reflection, CTFE would be just a bit more useful than folding.

On Sunday, 1 November 2020 at 07:27:09 UTC, Paulo Pinto wrote:

>
> Even C has issues with adoption among some embedded domains where the community is focused on C89 with OEM extensions and doesn't care about anything else.

Just going to pick on this para. sorry :)

I hear this a lot and it is simply not true. Working in embedded for the last ~18yrs (automotive and medical) every project since 2010 I know of is C++. At conferences and the like over the last 2-3yrs there is a lot of talk about Rust and people are starting to mention MicroPython for prototyping. But as a whole everyone I talk to is looking forward to upgrading their C++ compilers on the next project to get C++20 features.

Every C++ embedded project I have ever seen has exceptions turned off.


Cheers,
Norm

On Tuesday, 3 November 2020 at 06:04:26 UTC, norm wrote:
> On Sunday, 1 November 2020 at 07:27:09 UTC, Paulo Pinto wrote:
>
>>
>> Even C has issues with adoption among some embedded domains where the community is focused on C89 with OEM extensions and doesn't care about anything else.
>
> Just going to pick on this para. sorry :)
>
> I hear this a lot and it is simply not true. Working in embedded for the last ~18yrs (automotive and medical) every project since 2010 I know of is C++. At conferences and the like over the last 2-3yrs there is a lot of talk about Rust and people are starting to mention MicroPython for prototyping. But as a whole everyone I talk to is looking forward to upgrading their C++ compilers on the next project to get C++20 features.
>
> Every C++ embedded project I have ever seen has exceptions turned off.
>
>
> Cheers,
> Norm

Then you live in a happy bubble,

CppCon 2016: Dan Saks “extern c: Talking to C Programmers about C++”

https://www.youtube.com/watch?v=D7Sd8A6_fYU

https://embeddedgurus.com/barr-code/2018/02/c-the-immortal-programming-language/

Since you work in the industry, maybe you want share some reports that prove otherwise?

On 11/2/2020 10:04 PM, norm wrote:
> Every C++ embedded project I have ever seen has exceptions turned off.

I actually looked at implementing EH for DOS C++ programs. It's technically possible, but quite useless, as the necessary EH code would consume the entire 640Kb of memory :-/

On Tuesday, 3 November 2020 at 07:29:52 UTC, Walter Bright wrote:
> On 11/2/2020 10:04 PM, norm wrote:
>> Every C++ embedded project I have ever seen has exceptions turned off.
>
> I actually looked at implementing EH for DOS C++ programs. It's technically possible, but quite useless, as the necessary EH code would consume the entire 640Kb of memory :-/

Yep, binary bloat is the biggest factor but also the unpredictability of the unwind. If resources run out during the unwind the system can and does unexpected things. If you're lucky you get a bus error.

With exceptions turned off the most common approach is a brutal but effective one. An ENFORCE function, usually called ASSERT, that takes a predicate. If the predicate fails it writes the failure reason to an area in flash that persists across boot then sits in a while loop waiting for the HW watchdog to kick in. Any pending failure reason is reported on the next boot.

Cheers,
Norm