On Mon, 24 Mar 2025 at 21:10, Martyn via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
> - Tsoding made a pretty big fuss about "BetterC disabling dynamic arrays" but, again, his behaviour is a mix of humour and troll as well.
>

He probably just assumed there should be an array in the library (and he's
right to do so!). It probably didn't occur to him that things like arrays
and maps were intimately tied to the GC.
There should be containers in the library, and then we can remove that text
from the spec.
...but there's not! and there's reasons why...

On Tuesday, 25 March 2025 at 05:19:08 UTC, Manu wrote:
> On Mon, 24 Mar 2025 at 21:10, Martyn via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> - Tsoding made a pretty big fuss about "BetterC disabling dynamic arrays" but, again, his behaviour is a mix of humour and troll as well.
>
> He probably just assumed there should be an array in the library (and he's right to do so!). It probably didn't occur to him that things like arrays and maps were intimately tied to the GC.
> There should be containers in the library, and then we can remove that text from the spec.
> ...but there's not! and there's reasons why...

Despite the fact that they're tied to the GC, I rather assumed one could create a library based version, which could preserve the array and slice syntax for use.  Declaration may well have to differ (using some form of template?)

Albeit they'd likely leak depending upon just how they were used.  c.f. Odin having dynamic arrays despite no GC.

On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus wrote:
> On Tuesday, 25 March 2025 at 05:19:08 UTC, Manu wrote:
>> On Mon, 24 Mar 2025 at 21:10, Martyn via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>> - Tsoding made a pretty big fuss about "BetterC disabling dynamic arrays" but, again, his behaviour is a mix of humour and troll as well.
>>
>> He probably just assumed there should be an array in the library (and he's right to do so!). It probably didn't occur to him that things like arrays and maps were intimately tied to the GC.
>> There should be containers in the library, and then we can remove that text from the spec.
>> ...but there's not! and there's reasons why...
>
> Despite the fact that they're tied to the GC, I rather assumed one could create a library based version, which could preserve the array and slice syntax for use.  Declaration may well have to differ (using some form of template?)
>
> Albeit they'd likely leak depending upon just how they were used.  c.f. Odin having dynamic arrays despite no GC.

Nothing special, after all Ada, Object Pascal/Delphi, Modula-2, Zig, C++ all provide them, also without GC, and without leaking assuming correct use, as they use the respective managed features available.

So indeed, there would be a way to have them without GC, but boils down to having multiple vocabulary types, and libraries needing to decide what approach to support.

On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus wrote:
> On Tuesday, 25 March 2025 at 05:19:08 UTC, Manu wrote:
>> On Mon, 24 Mar 2025 at 21:10, Martyn via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>> - Tsoding made a pretty big fuss about "BetterC disabling dynamic arrays" but, again, his behaviour is a mix of humour and troll as well.
>>
>> He probably just assumed there should be an array in the library (and he's right to do so!). It probably didn't occur to him that things like arrays and maps were intimately tied to the GC.
>> There should be containers in the library, and then we can remove that text from the spec.
>> ...but there's not! and there's reasons why...
>
> Despite the fact that they're tied to the GC, I rather assumed one could create a library based version, which could preserve the array and slice syntax for use.  Declaration may well have to differ (using some form of template?)
>
> Albeit they'd likely leak depending upon just how they were used.  c.f. Odin having dynamic arrays despite no GC.

Indeed, I wrote my own 'DynArray' type for use in betterC. Declaration is with 'DynArray!int intArray' for example. I then used overloads for opSlice and such to get pretty much the same functionality (e g. auto slice = intArray[2..4]). I can also wrap that with a reference counted type to help avoid leaks if lifetime and scope varies :)

On Tuesday, 25 March 2025 at 11:19:04 UTC, Mike Shah wrote:
> On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus wrote:
>> [...]
>
> Indeed, I wrote my own 'DynArray' type for use in betterC. Declaration is with 'DynArray!int intArray' for example. I then used overloads for opSlice and such to get pretty much the same functionality (e g. auto slice = intArray[2..4]). I can also wrap that with a reference counted type to help avoid leaks if lifetime and scope varies :)

How about a session in your channel with him? :)

On Wednesday, 26 March 2025 at 15:58:54 UTC, Mengu wrote:
> On Tuesday, 25 March 2025 at 11:19:04 UTC, Mike Shah wrote:
>> On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus wrote:
>>> [...]
>>
>> Indeed, I wrote my own 'DynArray' type for use in betterC. Declaration is with 'DynArray!int intArray' for example. I then used overloads for opSlice and such to get pretty much the same functionality (e g. auto slice = intArray[2..4]). I can also wrap that with a reference counted type to help avoid leaks if lifetime and scope varies :)
>
> How about a session in your channel with him? :)

Nah.. tsoding is mostly a C guy

On Wednesday, 26 March 2025 at 15:58:54 UTC, Mengu wrote:
> On Tuesday, 25 March 2025 at 11:19:04 UTC, Mike Shah wrote:
>> On Tuesday, 25 March 2025 at 09:26:45 UTC, Derek Fawcus wrote:
>>> [...]
>>
>> Indeed, I wrote my own 'DynArray' type for use in betterC. Declaration is with 'DynArray!int intArray' for example. I then used overloads for opSlice and such to get pretty much the same functionality (e g. auto slice = intArray[2..4]). I can also wrap that with a reference counted type to help avoid leaks if lifetime and scope varies :)
>
> How about a session in your channel with him? :)

That would be fun if I could get in touch.