On Monday, 11 November 2019 at 21:54:23 UTC, Jonathan M Davis wrote:
> Both ~ and ~= use the GC, and it should be obvious that they do, since they can't work if they don't. Using ~ isn't any clearer than ~=, and ~ has worse performance when a dynamic array is able to grow in-place.

a~b is easier to deal with in code analysis than a~=b because the latter has unknown aliasing properties.

The compiler knows more when you can either say "will always reallocate" or "will never reallocate".

An optimizer could always do it in place if it is known to be safe. Especially in a loop or in a series of concatenations.

On 11/11/2019 12:50 PM, Meta wrote:
> Would it be enough to put an assert in GC.realloc/extend/free that asserts the memory is GC-owned, maybe tied to a compiler switch?

Currently, for `a~=b` if `a` is not owned by the GC, it is copied to a new GC location by the runtime.

On Monday, 11 November 2019 at 21:59:36 UTC, Paolo Invernizzi wrote:
> On Monday, 11 November 2019 at 21:49:52 UTC, Basile B. wrote:
>
>> 2. When not possible anymore, e.g function parameter, a @slice attribute could be used to apply the same restriction as in 1.
>
> O God, please no! Pretty frankly, writing D cose is starting to became a masterclass of attribute handling: with move semantic, rvalue, live, and now that, I've practically lost the count!

TBH me too. @safe could be used instead but then much more breakage to expect.

On Monday, 11 November 2019 at 18:13:45 UTC, Ola Fosheim Grøstad wrote:
> Maybe a type that will share the binary interface of C++ span and string_view. They are supposed to be the ones to use in function C++ function signatures to increase interoperability between libraries etc.
>
> Right now it is a bit difficult to say how span<> will be adopted in C++ libraries, but I would imagine that it might end up being used for matrices as well "span<span<T>>". So binary compatibility could make sense.

(A bit OT)

We tried to convince Walter to make extern(C++) void f(int[]) Just Work™, to no avail, because he though that it would b "unintuitive" for people to have include a header to have to use it. Go figure.

I doubt that span<span<T>> will be widely used, because jagged matrices are a bit of an odd choice of structure, span<string_view> might get a bit of use though.

On Monday, 11 November 2019 at 21:34:39 UTC, Walter Bright wrote:
> On 11/11/2019 3:26 AM, Nicholas Wilson wrote:
>> The breaking changes are massive and not well argued for.
>> The suggested workaround of
>> 
>> 1) a = a ~ b;
>> 
>> in place of
>> 
>> 2) a ~= b;
>> 
>> is functional identical, thus any issues present in 2 are also present in 1.
>
> The point is making it obvious that the GC is being used, i.e. it is intentional behavior.

and ~= doesn't? As noted elsewhere there is no safety issues with it because the GC will copy the slice or fill up available capacity. This entire line of reasoning is a non-sequiter.

On Monday, 11 November 2019 at 21:41:14 UTC, Walter Bright wrote:
> On 11/11/2019 5:13 AM, Dennis wrote:
>> ```
>> int[] slice = cast(int*)malloc(10 * int.sizeof)[0 .. 10];
>> slice = slice ~ 1; // now guaranteed to make a copy
>> free(slice.ptr); // Still oops
>> ```
>
> Imagine these 3 lines are spread out over a large code base.

People doing manual memory management without RAII deserve the codebase complexity  they get.

>> The following claim in the DIP is also unsubstantiated:
>> 
>>> This change is a necessary part of D evolving towards being memory safe without using
>>> a GC.
>
> Memory safety cannot be achieved without control over who is the owner of memory.
>
>> I would like to see an example of memory corruption in `@safe` code that can happen because of slice appending.
>
>   @trusted void myfree(void* p) { free(p); }
>   free(slice.ptr);

As noted elsewhere that is a broken @trusted, and therefore a user fault, not a language fault. This is no different to breaking the type system in any other way.

On 11/11/2019 2:33 PM, Paolo Invernizzi wrote:
> On Monday, 11 November 2019 at 22:28:05 UTC, Walter Bright wrote:
> 
>> We either get on the bus or get run over by the bus.
> 
> Frankly speaking, I've read such argumentations a lot of times along many years in the D history: the concurrency chapter of the D Programming Language is here to testify that this type of argumentation should be avoided, in a technical discussion.
> 
> Let's move forward from that, and let's try to find a sound solution to the memory safety problem, but without killing the language in the attempt.
> 
> There's no hurry: D is _already_ a safe language, thanks to your intuition of 20 years ago to bake the GC.

D is quite a bit safer currently than C or C++, but we've been a bit complacent about that advantage and are at risk of falling behind.

I am replying to the question about what is the direction D is going. This is the direction and the motivation for it. Whether DIP 1025 is the correct move in that direction or not is certainly worthy of technical discussion.

BTW, after not having memory corruption bugs for years, I've lost days of work in the last couple months looking for the cause of two memory corruption problems in DMD. I had grown complacent.

On Monday, 11 November 2019 at 10:27:26 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1025, "Dynamic Arrays Only Shrink, Never Grow":
> [...]

I also find it a problem that dynamic arrays do not carry their allocator in their type, hence the problem with reallocation. It works for a GC only language and many people think of D like this and are not complaining about it, so their voice should be given the importance that it deserves. In addition, D also wants to compete in convenience with scripting languages. Clearly there is a good argument on both sides. A separation between a slice and an array which knows its allocator is needed, but the convenience hit is too big for those who never in their life called malloc, so it's hard to make a good decision on this.

In general, D has made good decisions so far regarding this issue. For people who just want the convenience then things are great, the GC is dominant, malloc is @system so they need to be careful with it. And for those who want to control memory allocation they have to use @nogc.

The problem comes when these two worlds talk to each other, the @nogc world and the convenience world, the medium they use is a slice. But I don't find it that much of a problem, since the convenience world will never manually allocate or free anything, and the @nogc world cannot assume anything about who allocated a slice, that's the beauty of the slice, that it's very portable.

On Tuesday, 12 November 2019 at 00:51:28 UTC, Walter Bright wrote:
> On 11/11/2019 2:33 PM, Paolo Invernizzi wrote:
>> On Monday, 11 November 2019 at 22:28:05 UTC, Walter Bright wrote:
>> 
>>> We either get on the bus or get run over by the bus.
>> 
>> Frankly speaking, I've read such argumentations a lot of times along many years in the D history: the concurrency chapter of the D Programming Language is here to testify that this type of argumentation should be avoided, in a technical discussion.
>> 
>> Let's move forward from that, and let's try to find a sound solution to the memory safety problem, but without killing the language in the attempt.
>> 
>> There's no hurry: D is _already_ a safe language, thanks to your intuition of 20 years ago to bake the GC.
>
> D is quite a bit safer currently than C or C++, but we've been a bit complacent about that advantage and are at risk of falling behind.
>
> I am replying to the question about what is the direction D is going. This is the direction and the motivation for it. Whether DIP 1025 is the correct move in that direction or not is certainly worthy of technical discussion.
>
> BTW, after not having memory corruption bugs for years, I've lost days of work in the last couple months looking for the cause of two memory corruption problems in DMD.

How have you not had this problem before? DMD's code base is kind of horrible. Pointers to arrays that end up having to be accessed by (*p)[x]. A simple wrapper could easily have alleviated that entirely. It's kind of ironic that the D reference compiler showcases exactly how you shouldn't write D code.

> I had grown complacent.

And now you are over eager to make changes to change that complacency. These DIPs are being ejected out one after another. It seems like everything else is being thrown under the bus on this hellbent pursuit of safety.

> ... the former at compile time and the latter at runtime (as a dynamic check is necessary). Hence, a long deprecation period will be necessary.

Of all the things people would be willing to have such a big breaking changes for. Auto-decoding to name one. This is now where the line is drawn? Some of these decisions are being made too hastily IMO.

On 11/11/2019 7:24 AM, jmh530 wrote:
> malloc is also only allowed in @system code.

Although malloc() is marked as @system, it actually is @safe. It's free() that needs to be @system.