On Tuesday, 12 November 2019 at 09:12:51 UTC, Robert Schadek wrote:
> golang is not going in that direction. They are not @safe but mostly because they have chosen performance over safety.

You have to make an effort to break Go. You can do that with most languages...

In practice Go is an alternative to languages like Java, C# and Python. Like Java it is much more
its own virtual environment (but unix influenced) than a system level programming language. Which makes sense for web-services.

On Tuesday, 12 November 2019 at 10:09:05 UTC, Ola Fosheim Grøstad wrote:
> In practice Go is an alternative to languages like Java, C# and Python. Like Java it is much more
> its own virtual environment (but unix influenced) than a system level programming language. Which makes sense for web-services.

Hm, when I think of go I think of docker/kubernetes.
For me that is systems programming.
I see your point, but I think there are other ways to look at it.
You can actually get Microcontrollers that run python not c.

I think saying, and I'm not saying you say that, systems programming therefore
mmm is at least a "Hasty Generalization".

On Tuesday, 12 November 2019 at 09:12:51 UTC, Robert Schadek wrote:
> On Monday, 11 November 2019 at 22:28:05 UTC, Walter Bright wrote:
>> Although malloc() is marked as @system, it actually is @safe. It's free() that needs to be @system.
>
> I think that is a mute point.

(You mean moot point)

> malloc gives you a void*, you can't really do anything with that void*
> in @safe code.
> You can't even cast it to int*, and it shouldn't.
>
> I know I sound like a broken record, but IMO mmm and @safe is the wrong direction.

Thats what containers are for, to encapsulate the inherent unsafety and expose a safe interface.

> Generative programming in combination with functional programming, is
> awesome. Hardly anybody is doing that.
> I'm not saying we should steal other peoples good ideas.
> I'm trying to say we should steal interesting ideas/mistakes and improve on them.

We should definitely steal them, but we had better a) make sure they are good ideas, and b) understand what makes them good. Otherwise we risk doing what C++ did with static if/constexpr if, UFCS and many more.

> For instance taking the c++ template meta-programming mistake and
> making it a feature was a huge win.
>
> Additionally, I think there is an elephant in the room. Multi-threading.
> I just watched a talk on rust async/await.
> https://www.youtube.com/watch?v=lJ3NC-R3gSI
> It took them ~10 years to get the borrow-checker + multi threading thing
> done/right, and compared to us they have infinite resources.
> Is there a plan for D and the borrow-checker in place/planning?

That would be DIP1024[1], which follows the same proof of safety by induction of @trusted leaf functions for encapsulating safe access to members with locks/atomics/etc.

[1]:https://github.com/dlang/DIPs/blob/master/DIPs/DIP1024.md

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":
>
> https://github.com/dlang/DIPs/blob/1b525ec4c914c06bc286c1a6dc93bf1533ee56e4/DIPs/DIP1025.md
>
> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on November 25, or when I make a post declaring it complete.
>
> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.
>
> Anyone intending to post feedback in this thread is expected to be familiar with the reviewer guidelines:
>
> https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md
>
> *Please stay on topic!*
>
> Thanks in advance to all who participate.

If you create a slice from manually managed memory, you probably also have to make sure the slice does not outlive the memory. This means the slice has to be passed as scope to functions (or some pure functions). The DIP should only apply to scope slices, because other slices are probably allocated on the GC.

On Monday, 11 November 2019 at 22:28:05 UTC, Walter Bright wrote:
> The idea is to be able to guarantee memory safety. I've spoken about this in my presentations and DConf, and that's clearly what DIP25 and DIP1000 were targeted at, and my proposals for an Ownership/Borrowing system for D.
>
> This is where the industry is moving. Even C++ is heading that direction:
>
>   http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1179r0.pdf
>
> This proposal is written by Herb Sutter, and is no joke.
>
> We either get on the bus or get run over by the bus.

I feel like if this proposal is part of the motivation for this DIP, then it should be mentioned in the DIP.

On 12.11.19 11:37, Nicholas Wilson wrote:
> 
> We should definitely steal them, but we had better a) make sure they are good ideas, and b) understand what makes them good. Otherwise we risk doing what C++ did with static if/constexpr if, UFCS and many more.

Actually it will be even worse because we don't follow C++'s backwards-compatibility mantra. To me it appears that Walter wants to dismantle the GC piece by piece.

On Tuesday, November 12, 2019 1:43:27 AM MST Robert Schadek via Digitalmars- d wrote:
> On Tuesday, 12 November 2019 at 03:08:28 UTC, Walter Bright wrote:
> > Although malloc() is marked as @system, it actually is @safe.
> > It's free() that needs to be @system.
>
> I think that is a mute point.
> malloc gives you a void*, you can't really do anything with that
> void*
> in @safe code.
> You can't even cast it to int*, and it shouldn't.
>
> I know I sound like a broken record, but IMO mmm and @safe is the wrong direction.

Honestly, I don't think that it can really be done without seriously hamstringing ourselves.

Dynamic arrays and manually managed memory are a _terrible_ combination, because dynamic arrays do nothing to manage lifetimes. They're really not any different from passing naked pointers around as far as lifetime tracking goes. This means that the only way that you can automatically manage that is to restrict where they can be stored. scope does that, but the result is that you can pretty much just pass the data into a function that operates on it and doesn't store it. It doesn't even allow you to do something as simple as have the function return a range wrapper like a lot of Phobos does. And real world code typically needs to store stuff, not just pass it around. Maybe what Walter is looking to do with @live will let it go a bit further, but I don't see how it could possibly allow anywhere near the freedom you get when passing around dynamic arrays that are slices of GC-allocated memory. You end up throwing all kinds of complications into the mix just to try to get a bit more @safety for non-GC-allocated memory. Maybe some of those complications are worth it, but at some point, it's just too much extra machinery for too little benefit, and I'd argue that if it harms common use patterns of GC-allocated objects (which this DIP definitely does), then it's going to far.

Personally, I don't think that it makes much sense to try to improve passing around naked slices of malloc-ed memory. The lack of lifetime management makes it so that you can't possibly guarantee that it's @safe to free the memory without severely restricting what's allowed, and in general, I'd strongly argue that in most cases, it's bad practice to pass around naked slices of malloc-ed memory unless what the code is deing is restricted enough that the programmer knows what's being done with that memory so that they can know when it's safe to free it. Some use of features like scope may help make it more manageable, but I think that it's folly to expect code to do something like

auto arr = (cast(int*)malloc(length * int.sizeof))[0 .. length];

pass that memory around, and then later do

free(arr.ptr);

and have that be @safe. Outside of simple examples, to pass around malloc-ed memory @safely, it needs to be wrapped in a type that manages its lifetime (e.g. a smart pointer). Language improvements (like DIP 1000) may make it easier to manage when pointers or references to that memory temporarily escape the smart pointer in order to operate on it, but to pass around and store that memory like you'd frequently do with GC-allocated memory, it needs to be wrapped in something that manages its lifetime, just like you'd do in languages like C++.

Regardless, even if all agreed that we wanted to improve the @safety of malloc-ing a naked dynamic array, passing it around, and then freeing it, I don't see how this DIP really helps with that. As has been pointed out already in this thread, simply mutating the dynamic array itself screws with your ability to get the pointer from it to free (showing that you really should be storing a pointer for that separately regardless of what's going on with appending), and appending doesn't cause any @safety problems. It just makes it harder to track whether the dynamic array still refers to any portion of that malloc-ed memory, but even then, it doesn't make it impossible to do so, and if you want to forbid appending, you can simply require that the code be @nogc. So, the DIP fails to even do what it's trying to do, and in the process, it hurts very common use cases.

- Jonathan M Davis

On Tuesday, 12 November 2019 at 10:25:40 UTC, Robert Schadek wrote:
> Hm, when I think of go I think of docker/kubernetes.
> For me that is systems programming.
> I see your point, but I think there are other ways to look at it.
> You can actually get Microcontrollers that run python not c.

Yep, that is true.

> I think saying, and I'm not saying you say that, systems programming therefore
> mmm is at least a "Hasty Generalization".

Yes.

I think the long term future even for embedded programming is high level languages that allows you to "bind" datastructures to low level representations where you need them (but otherwise leave it to the compiler).

So yes, how to do systems programming will hopefully evolve over time.

But for me there ought to be a separation between high level and low level constructs. In C++ all high level types are library only, that means the compiler can only do low level optimization. D has some room to innovate there, so I certainly am sympathetic to the idea that high level features should not be undermined. Maybe the question ought to be, can the high level features be strenghtened in a way that allows the compiler to be smarter and that allows the compiler to "understand" where low level assumptions are being made and where it has free hands to be smart. So rather than downgrading high level construct, upgrade them from runtime-constructs to compiler-constructs.

It is quite intriguing though that something as simple as slices can be so complex to figure out. I've written some variations of slices for C++ before they added it, and there are so many trade offs... Maybe one has to classifiy all the different use scenarios for slice-like types and then figure out some solution that allows the compiler to be more clever than in other languages.

On Monday, 11 November 2019 at 22:40:44 UTC, Jonathan M Davis wrote:
> On Monday, November 11, 2019 2:41:14 PM MST Walter Bright via Digitalmars-d wrote:
> It should be clear to anyone seriously using dynamic arrays that
>
> int[] slice = cast(int*)malloc(10 * int.sizeof)[0 .. 10];
> slice ~= 1;
> free(slice.ptr); // Oops!
>
> is a problem. It's a given that appending can cause a reallocation. But even if appending weren't allowed, you could still have something like
>
> int[] slice = cast(int*)malloc(10 * int.sizeof)[0 .. 10];
> slice = slice[1 .. $];
> free(slice.ptr); // Oops!
>
> and have problems, because the dynamic array isn't slicing the beginning of that block of memory anymore.

+1
It was my first thought

On Tuesday, 12 November 2019 at 08:41:52 UTC, Sebastiaan Koppe wrote:
>
> I would personally look at the conflation of dynamic arrays and slices. If you could somehow separate the 2 concepts and THEN constrain slices to only be able to shrink, that might work.

Yes, this DIP needs to be suspended until we know what to do with the divorce between dynamic arrays and slices.