On Tuesday, 29 November 2022 at 18:59:46 UTC, DLearner wrote:

I have implemented that in styx.

1. You have the type for dynamic arrays, called TypeRcArray, syntax is Type[+]
2. You have the type for slices (what you describe as a window), syntax is Type[]
   but it is mostly obtained using expressions, e.g mySlice = myRcArray[lo .. hi] or
   myStaticArray[lo .. hi] or myPointer[lo .. hi].

This sounded like a good idea but it has appeared very quickly that slices are not so useful, especially when management is based on reference counting because then slices requires a form of management too. Here is why:

Main caracteristics of a slice are

• they cannot modify the identity of their sources. The identity of the source is what makes the integrity of a dynamic array, what makes their references countable. So it is the content pointer and the length. In consequence you cannot change the length of the source, you can only reduce the view. You can change the elements in the view.
• the length and the pointer are cached as a value on the stack while for a dynamic array this is stored before that data, on the heap.

Problems start happening when you escape a slice

struct S
{
    var s32[] memberSlice;
}

function f(var S s): auto
{
    var s32[+] a = (new s32[+])(2);

    // problem 1 : `s` lifetime > `a` lifetime
    s = (a[]).tupleof;  // note: tuples are used in pace of struct literals

    // problem 2
    return a[1 .. $]; // a is automatically decref'd on return
                      // so the caller pulls a dead heap block.
}

Essentially slices are only useful to be consumed locally, typically

while mySlice.length do
{
   slice = slice[1..$];
}

And that's it. So at first glance slices are some cool, simplified, functionally stripped down arrays but they introduce new problems, at least when management of dynamic arrays is based on reference counting. Those new problems can only be solved using lifetime analysis (so a compile-time check... still better than runtime ref counting however).

On Wednesday, 30 November 2022 at 03:04:47 UTC, Basile B. wrote:

while mySlice.length do
{
   slice = slice[1..$];
}

sorry I cant force push, it was obviously meant to be written as

while mySlice.length do
{
   mySlice = mySlice[1..$];
}

On Wednesday, 30 November 2022 at 02:29:03 UTC, Paul Backus wrote:

[...]

I agree should not change existing meaning of

int[] A;

But why not allow a construct for value-type variable arrays like:

int[*] B;

Best regards

On Saturday, 3 December 2022 at 22:46:31 UTC, DLearner wrote:

int[] A;

int[*] B;

There's no reason to add more complexity to the language for this when the same result can already be achieved using existing language features.

On Wednesday, 30 November 2022 at 03:04:47 UTC, Basile B. wrote:

Recently DIP1044 was published about enum and although we can use with() instead we waste time unnecessarily...

I've never tried it, but the feature shown below is not available in D! Why not such good things?

enum Foo
{
     a0 = 1,
     a1
}

enum Bar: Foo
{
    a2 // 3
}

Thanks...

SDB@79

On Sunday, 4 December 2022 at 09:54:53 UTC, Salih Dincer wrote:

With cannot be used in calls.
Hence when calling a function you need to either spell out the enum type or wrap the call in a with or multiple withs.

enum Foo
{
     a0 = 1,
     a1
}

enum Bar: Foo
{
    a2 // 3
}

This is easy to add and costs almost no complexity