[WIP] Add @nogc array

[edi33416]

This PR adds a @nogc nothrow pure @safe implementation of a generic array that mimics the behaviour of the built-in array (T[]).

This array implementation makes use of the Copy Constructor PR. By doing so, it both tests the implementation and proves it's usefulness.

I know this is a lengthy PR, but please bear with me, as there are a lot of unittests.
And now, as Andrei says "destroy()"

[dlang-bot]

Thanks for your pull request and interest in making D better, @edi33416! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + druntime#2348"

[jacob-carlborg]

Needs to handle non D classes.

[edi33416]

Got it. What non D classes are supported? C++ ones?

[jacob-carlborg]

In addition to C++ classes: Objective-C classes and interfaces and COM interfaces.

[andralex]

@jacob-carlborg that was copied from the phobos implementation (later to be moved), can you explain what needs to be done here? Thanks! Also: would rather add that as an additional PR after this.

[jacob-carlborg]

TypeInfo is somewhat broken for non D classes. But emplace might not be affected. Test it and see what happens and make sure to add tests for it.

[wilzbach]

Should be private then.

[edi33416]

What do you guys think about moving emplace to core.internal.traits ?

[jacob-carlborg]

It's not really a trait is it?

[edi33416]

You are right. My bad, sorry :).
The question remains: should we move it into a core.internal.conv ?

I think emplace is especially usefull when you want to construct an immutable object into a predefined memory area.

[andralex]

Let's make it private for now and postpone that decision. Fight one fight at a time.

[jacob-carlborg]

Needs to handle non D classes and interfaces.

[edi33416]

Same question: can you please provide me with an example?

[jacob-carlborg]

Replied to the other comment.

[jacob-carlborg]

Should have tests with non D classes as well.

[jacob-carlborg]

• There’s a lot of code related to traits, do we want that in the same module?
• Why are some range functions included and why are they in the Array struct?

[jacob-carlborg]

This exists as well
https://github.com/dlang/druntime/blob/master/src/rt/util/container/array.d.

[edi33416]

* There’s a lot of code related to traits, do we want that in the same module?

There is, and I want to remove as much as I can. I didn't know about core.internal.traits until like 10mins ago.
Regarding core.internal.traits, I see there is a duplicate of the Phobos Unqual there. I'll open a PR in Phobos that will alias to core.internal.traits.Unqual, so we won't have to maintain the same code twice.

* Why are some range functions included and why are they in the Array struct?

I needed those for some of the template constraints and other in order to consume T[]

[jacob-carlborg]

I needed those for some of the template constraints and other in order to consume T[]

If they’re only for implementation they should be private.

[edi33416]

I'll open a PR in Phobos that will alias to core.internal.traits.Unqual, so we won't have to maintain the same code twice.

Said PR.

[andralex]

TODO: rename module to rcslice.d and type name with rcslice.

[andralex]

All: would rcarray be preferable to rcslice?

[edi33416]

Changing to
this(scope immutable ref typeof(this) rhs) immutable fix the scope error, but will make the ctor @system.
Adding a @trusted (For testing purposes only) to quickly mute all the complaints will pass all the tests. Why is the scope required and why is it making the function @system when used?

[edi33416]

Another way of bypassing the error, without any @trusted "magic" is to change the idup implementation from

immutable(rcarray!T) idup(this Q)()
{
    return immutable rcarray!T(this);
}

to

immutable(rcarray!T) idup(this Q)()
{
    static if (is(Q == immutable))
    {
        return this;
    }
    else
    {
        return immutable rcarray!T(this);
    }
}

[anon17]

The is condition in PrefixAllocator is always true.

alias localAllocator = shared PrefixAllocator.instance;
alias sharedAllocator = shared PrefixAllocator.instance;

shared looks out of place here.