On 2020-10-30 10:15, Daniel Kozak wrote:

> Nice DIP, but why not added as a https://dlang.org/phobos/core_attribute.html this would mean no breaking change

Technically any new public symbol can cause a breaking change. But a compiler recognized UDA is less likely to cause a breaking change than a  built-in attribute. And if it is breaking some code, it can be resolved by using fully qualified name (or similar techniques). There's no need to rename the UDA.

-- 
/Jacob Carlborg

On 2020-10-29 22:57, Paul Backus wrote:

> I have a DIP I think you'll like:
> 
> https://github.com/dlang/DIPs/blob/02594a09d9daf1d393ebce2cfc2f0c4f90d4bcf8/DIPs/1NNN-PJB.md 

Your main rationale seems to be error handling without exceptions. In my opinion there are better ways to deal with error handling than returning errors. For example, there's nothing wrong with exceptions per se (well, a few details), it's just that the implementation is a bit unfortunate. In my opinion there's nothing that stops exceptions on being implemented in some other way, that does not require the runtime. Like a Result struct or as tagged unions with some help from the compiler.

The following code:

enum Error
{
    fileNotFound
}

string readFile(string path) throw(Error)
{
    throw Error.fileNotFound;
}

void foo() throw(auto)
{
    string content = try readFile("foo.txt");
}

void bar()
{
    try
        bar();
    catch (Error e)
        writeln("An error occurred: ", e);
}

Can be lowered to something like:

struct Result(Value, Error)
{
    Value value;
    Error error;
    bool isSuccessful;

    this(Value value)
    {
        this.value = value;
        isSuccessful = true;
    }

    this(Error error)
    {
        this.error = error;
        isSuccessful = false;
    }
}

Result!(string, Error) readFile(string path) nothrow
{
    return Result!(string, Error)(Error.fileNotFound);
}

Result!(void, Error) foo() nothrow
{
    string content;
    auto __result = readFile("foo.txt");

    if (__result.isSuccessful)
        content = __result.value;
    else
        return Result!(void, Error)(__result.error);
}

void bar() nothrow
{
    auto __result = bar();

    if (!__result.isSuccessful)
        writeln("An error occurred: ", __result.error);
}

Have a look at this C++ proposal [1] by Herb Sutter and the error handling in Zig [2].

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf
[2] https://ziglang.org/documentation/master/#Errors

-- 
/Jacob Carlborg

On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>
> D popularized CTFE, and other languages followed suit, including Jai.

Yes I agree, I was being picky about the wording. Jai et al. have taken features from D and adopted them, but Jai is definitely not _mimicking_ D, in the sense of trying to be like D in general.

On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>
> D popularized CTFE, and other languages followed suit, including Jai.

Sorry but that flag belongs to Lisp and Dylan macros, Java compiler plugins, Java/.NET manipulation of attributes/annotations and C++ template meta-programing.

D CTFE has definitely a very important value, but not everything that other languages adopt was created by D.

On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>
> D popularized CTFE, and other languages followed suit, including Jai.

Indeed - Jai can be thought of as a cut-down version of D without GC, but with CTFE. I don't have access to Jai but from what I observe, D has everything Jai has.

Zig seems like a copy of Jai.

Neither of these languages offer anything new (from what I can see) - and that was my argument about better branding for 'leaner D' - which is not the same as 'better C'.


Regards

On Saturday, 31 October 2020 at 17:18:30 UTC, Dibyendu Majumdar wrote:
> On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
>> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>>
>> D popularized CTFE, and other languages followed suit, including Jai.
>
> Indeed - Jai can be thought of as a cut-down version of D without GC, but with CTFE. I don't have access to Jai but from what I observe, D has everything Jai has.
>
> Zig seems like a copy of Jai.
>
> Neither of these languages offer anything new (from what I can see) - and that was my argument about better branding for 'leaner D' - which is not the same as 'better C'.
>
>
> Regards

D has everything that Algol has - that doesn't mean that Algol copied D.

On Saturday, 31 October 2020 at 17:35:34 UTC, Abdulhaq wrote:
> D has everything that Algol has - that doesn't mean that Algol copied D.

Hah, Simula added OO to the Algol family :-). Difficult to say what influenced what, but I can imagine that D influenced some C++ people to push harder for some features in C++17/C++20.

On Saturday, 31 October 2020 at 16:22:32 UTC, Paulo Pinto wrote:
> On Saturday, 31 October 2020 at 01:57:19 UTC, Walter Bright wrote:
>> On 10/29/2020 5:48 AM, Abdulhaq wrote:
>>> I'm pretty sure that Jai is not mimicking D, also I doubt that Zig is either.
>>
>> D popularized CTFE, and other languages followed suit, including Jai.
>
> Sorry but that flag belongs to Lisp and Dylan macros,

If CTFE means that you use the regular language then I guess dynamic languages would be the first, but then you may not have a clear separation between compilation and execution either. Of course there are many languages that do some of it, e.g. flexible type systems with generic unification/logic programming.

Why most language designers don't go all the way with the full language probably has a lot to do with:

1. debugging is difficult
2. compilation may not terminate
3. compilation will be slower
4. it is seen as an implementation optimization and not a language feature

But then again, computers are faster, have more memory and can spend more resources on static analysis so CTFE is perhaps primarly a consequence of technology... e.g. time.

On Saturday, 31 October 2020 at 17:41:08 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 31 October 2020 at 17:35:34 UTC, Abdulhaq wrote:
>> D has everything that Algol has - that doesn't mean that Algol copied D.
>
> Hah, Simula added OO to the Algol family :-). Difficult to say what influenced what, but I can imagine that D influenced some C++ people to push harder for some features in C++17/C++20.

Yeah we're talking "on the shoulders of giants" here, and it is possible that D could end up in that hall of fame at some time.

However, speaking to the original point, Jonathan Blow has a very different philosophy to Walter and Andrei, Jonathan is very games oriented, and Jai targets games development. D's CTFE probably had some influence on Jai (as did Lisp etc as Paulo pointed) out, but in no way did Jonathan think of, or approach, Jai as a cut down D.

On Saturday, 31 October 2020 at 17:53:14 UTC, Abdulhaq wrote:
> However, speaking to the original point, Jonathan Blow has a very different philosophy to Walter and Andrei, Jonathan is very games oriented, and Jai targets games development. D's CTFE probably had some influence on Jai (as did Lisp etc as Paulo pointed) out, but in no way did Jonathan think of, or approach, Jai as a cut down D.

Yes, most certainly. I did watch his videos a long time ago. He seemed to be very concerned with specific patterns that he feels is common in games programming. So Jai might end up having some special casing that other languages don't bother with. e.g. structs of arrays vs arrays of structs.

But, most Algolish C++-influenced languages are rather similar. We are basically talking flavours and runtime differences.