November 07, 2021

On Sunday, 7 November 2021 at 14:38:14 UTC, Alexandru Ermicioi wrote:

>

On Sunday, 7 November 2021 at 14:08:32 UTC, Basile B. wrote:

>
  • .length and .ptr becomes functions calls.
  • things like .length++ is not really supported, you have to make a Length struct for that

That would make sense, since even right now .length is not just a simple number, otherwise, you wouldn't be able change the size of an array (i.e. allocate more memory).

Actually I had in mind the simple fact to read array properties.

Good news, it turns out that this point is not valid, in both cases optimizers (must be the common subexpression optim) only read the property once (according to this).

> >
  • implicit conversions, templates constraints, would lead to plenty of templates instances (things like if (is(T == U[])) would require to instantiate U[] right ?)

No idea about it being instantiated in is template. Are templates instantiated when doing is expression checks? Question to people knowledgeable about this.

>
  • dynamic arrays are part of the type system, being TypeNext derived they share common methods with pointers and static arrays.

That would be a breaking change, if the struct is not treated specially by compiler (i.e. compiler replacing the type).

>
  • the internal type is still required (or plenty of special cases) so that for example errors message display the type representation correctly and not as lowered.

So perhaps the internal type could then be a wrapper over struct one? Could that solve the issue with internal representation, and perhaps the type system (previous statement)?

>
  • CTFE must use the new struct template too?

What do you mean by that?

I mean it must use the AST of the new templatized struct.

> >
  • apparently (recently read that elsewhere) control of the bound checks cannot be based on version

Why can't they?

Because versions are not part of the mangle, so when you link you don't know if what's been generated in a *.o has bound checks activated or not.

November 07, 2021

On Sunday, 7 November 2021 at 16:07:19 UTC, Teodor Dutu wrote:

>

I think the issue of array representation is a serious enough topic that it deserves its own separate thread. In addition, this issue is outside the scope of initial question, which revolves around the bug highlighted here:

Do you have any suggestions about it?

void-initialize your to-be-returned array in _d_arrayctor? Which BTW should also bring your attention to the fact that such a function can never be @trusted, and can only be as @safe as the actual ctor calls it would defer to.

November 07, 2021

On Sunday, 7 November 2021 at 17:01:20 UTC, Stanislav Blinov wrote:

>

On Sunday, 7 November 2021 at 16:07:19 UTC, Teodor Dutu wrote:

>

I think the issue of array representation is a serious enough topic that it deserves its own separate thread. In addition, this issue is outside the scope of initial question, which revolves around the bug highlighted here:

Do you have any suggestions about it?

void-initialize your to-be-returned array in _d_arrayctor?

Won't this be the same as doing this:

T[] to;  // to be returned
to.length = length;

The problem with this approach is that to isn't NRVO'd because the lowering to _d_arrayctor is only done for static arrays.

>

Which BTW should also bring your attention to the fact that such a function can never be @trusted, and can only be as @safe as the actual ctor calls it would defer to.

I used @trusted because some unittests that used this lowering were @safe. It was a compile-time workaround.

November 07, 2021

On Sunday, 7 November 2021 at 17:47:45 UTC, Teodor Dutu wrote:

> >

void-initialize your to-be-returned array in _d_arrayctor?

Won't this be the same as doing this:

T[] to;  // to be returned
to.length = length;

The problem with this approach is that to isn't NRVO'd because the lowering to _d_arrayctor is only done for static arrays.

??? No, it will not. The problem in your

Tarr1 _d_arrayctor(Tarr1 : T1[], Tarr2 : T2[], T1, T2)(scope Tarr2 from)
{
    Tarr1 to;
    // ...
    return to;
}

is the default initialization. S from the unittest is a nested struct, and can't be instantiated outside of scope of its parent. But this should work:

// Obviously concrete implementation would be generic here, and copy/blit accordingly. This one explicitly calls copy ctor for illustration purposes only.
Tarr1 _d_arrayctor(Tarr1 : T1[], Tarr2 : T2[], T1, T2)(scope Tarr2 from)
{
    // Infer @safe-ty from an actual ctor.
    // Note that is is a nuclear option. Ideally you'd check a trait,
    // something like isSafeCopyable!(T1, T2), which would need to be defined,
    // so that no code gets emitted here regardless of build options
    if (false) { T1* a; T2* b; (*a).__ctor(*b); }
    return () @trusted
    {
        Tarr1 to = void;
        foreach (i, ref it; to)
            it.__ctor(from[i]);
        return to;
    } ();
}

void main() @safe
{
    int counter;
    struct Nested
    {
        this(return ref scope typeof(this) n) { /* ... */ }
        ~this() { ++counter; }
    }

    Nested[3] arr1;
    Nested[3] arr2 = _d_arrayctor!(typeof(arr1))(arr1);
}

>

I used @trusted because some unittests that used this lowering were @safe. It was a compile-time workaround.

? It should pass unittests without lying to the compiler, by correctly inferring @safe-ty.

November 07, 2021

On Sunday, 7 November 2021 at 18:15:53 UTC, Stanislav Blinov wrote:

>

??? No, it will not. The problem in your

Tarr1 _d_arrayctor(Tarr1 : T1[], Tarr2 : T2[], T1, T2)(scope Tarr2 from)
{
    Tarr1 to;
    // ...
    return to;
}

is the default initialization. S from the unittest is a nested struct, and can't be instantiated outside of scope of its parent. But this should work:

[...]
Tarr1 to = void;
[...]

Thanks a lot! It worked.

> >

I used @trusted because some unittests that used this lowering were @safe. It was a compile-time workaround.

? It should pass unittests without lying to the compiler, by correctly inferring @safe-ty.

Yes, you're right. @trusted was more of a stop-gap solution in order to get the code to work in the first place. Now that it does, I should look into a nicer way of having @safe-ty inferred. I'll probably follow your advice here, too. Thanks again!

1 2
Next ›   Last »