June 01, 2019
On Friday, 31 May 2019 at 21:39:10 UTC, Manu wrote:
> A fun() { return A(); }
> B fun() { return B(); }
>
> fun(); // <- return value ignored
>
> ...?

In this instance it is a matter of "ideological" language semantics.

If the language "ideology" is spec-driven then compiler should be allowed to choose the one that does less work, given that they both are supposed to implement the same spec. The IDE can show which one is chosen, so I don't think it is as big a problem as people make it out to be (assuming you limit your imports).

If the language has error-as-return-value as an idiom, then it might require the caller to check all returned errors. In that case it should pick the function call  that throws if the caller does not use the returned value, and complain if both versions of "fun()" returns an error value.

Anyway, you can get around it by:

A _ = fun();    // _ is not used

or:

returns!A( fun() );  // wrapper that ensures the return type to be of A

June 01, 2019
Found some odd behavior, seems if a template needs to reference itself, it does not add the @nogc attribute to itself. Meaning it's type is not @nogc/nothrow, but it can still be called in @nogc functions. Unless you take a pointer to it, then it doesn't have the attributes so it can't be called.

https://run.dlang.io/is/YJDs7y

import std.stdio;

void test3(t)() {
    import core.stdc.stdio;
    printf("%s\n", t.stringof.ptr);
}

void test2(bool check)()  {
    static if(check) test3!(typeof(&test2))();
    else              test3!(int)();
}

void main() @nogc {

    auto p1 = &test2!false;
    auto p2 = &test2!true;
	
    test2!false();
    p1();

    test2!true(); // ok
    // p2(); // error can't call @nogc function

    printf("---\n%s\n%s\n", typeof(p1).stringof.ptr, typeof(p2).stringof.ptr);
}
June 02, 2019
On Saturday, 1 June 2019 at 12:08:50 UTC, Exil wrote:
> Found some odd behavior, seems if a template needs to reference itself, it does not add the @nogc attribute to itself. Meaning it's type is not @nogc/nothrow, but it can still be called in @nogc functions. Unless you take a pointer to it, then it doesn't have the attributes so it can't be called.
>
> [...]

I've made an issue here: https://issues.dlang.org/show_bug.cgi?id=19934
1 2 3 4 5
Next ›   Last »