On Wednesday, 29 August 2018 at 08:35:30 UTC, Walter Bright wrote:
> On 8/28/2018 10:18 PM, Nicholas Wilson wrote:
>> Bugzilla is not documentation. These are language changes they need to be in release notes and the spec.
>
> You asked for a clue: "we have no clue WTF its supposed to do or why the changes are being made" and there it is. There are no barriers to reviewing the idea nor the implementation.

I don't know how much more blunt I can be while still being professional about it:
_this must be documented properly_. This is not just about us reviewing it, this is also about people using it.

Think about it this way: I'm a new user and I hear that D is supposed to be memory safe.

Am I going to trawl through bugzilla to find about the features of this memory safety?

Suppose I do a search for "dlang memory safety" on how I can use this feature. What does a search bring up?

First hit: https://dlang.org/spec/memory-safe-d.html
Gives me a link to https://dlang.org/articles/safed.html, not very helpful, and to
 @system/@safe/@trusted, that tells me a bunch of things I'm not allowed to do in safe code.

Second hit: https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/
More (admittedly better) info on @system/@safe/@trusted

Third Hit: https://forum.dlang.org/thread/ofkjuq$or6$1@digitalmars.com welp the forum is down, next!

Fourth hit: https://wiki.dlang.org/Memory_Management

Fifth hit: https://dconf.org/2017/talks/bright.pdf
Some stuff about scope, possibly not up to date(!).

Sixth hit is Adam Ruppe's fork of the spec page on memory safety

Seventh is https://news.ycombinator.com/item?id=12391370

Number 8: https://www.meetup.com/en-AU/SeaLang/events/246692611/

9: https://www.reddit.com/r/cpp/comments/6b4xrc/walter_bright_believes_memory_safety_will_kill_c/

10: is the Wikipdia page on D.

Searching for "dlang scope" brings up scope(exit) & friends and some old forum posts  including https://forum.dlang.org/thread/obfftm$2m3j$1@digitalmars.com which feels like déjà vu, followed by a bunch of irrelevant links to various parts of the spec.

That was on a not anonymous search, I know precisely what I'm looking for, and the closest thing I found was 4/5ths the way down a 42 slide PDF with no annotations from a year ago.

Even someone relatively familiar is going to look at the spec and the changelog, and they're not going to find anything BECAUSE ITS NOT THERE! You know where it is? Bugzilla, because that's where Walter thinks documentation should go.

On Friday, 17 August 2018 at 07:19:25 UTC, Peter Alexander wrote:
>
> My question is: what is the status of @safe? I am quite surprised to see such a simple case fail. Is @safe believed to be fully implemented (modulo bugs) and this is just an unfortunate corner case, or is it known work-in-progress?

Years ago (2012-2013 https://forum.dlang.org/post/xibbzslaunogifsomapl@forum.dlang.org) I was arguing that @safe is crippled: 1) there is high probability that some loopholes are missing (several of them were posted to bugzilla and still not fixed since then) 2) fixing loopholes will make using @safe inconvenient.

My point is somewhat different from expressed already here by Jonathan. He speaks about whitelisting/blacklisting and that the former model will always contain loopholes. In my view, the reason is that memory safety in (essentially good old C) memory model depends on runtime memory type which is unrelated to static type. Taking random variable - it can be allocated on stack, heap, GC-heap, thread-local and there is no way at CT to determine this in general case. In other words, static type rules is bad approach to determine memory safety. It can be used to detect some obvious bugs, but does not work across compilation boundaries. The better approach in my view is to insert runtime code which performs some tests (at least this how C# works).

On Thursday, 30 August 2018 at 16:57:05 UTC, Maksim Fomin wrote:
> My point is somewhat different from expressed already here by Jonathan. He speaks about whitelisting/blacklisting and that the former model will always contain loopholes. In my view, the reason is that memory safety in (essentially good old C) memory model depends on runtime memory type which is unrelated to static type. Taking random variable - it can be allocated on stack, heap, GC-heap, thread-local and there is no way at CT to determine this in general case. In other words, static type rules is bad approach to determine memory safety. It can be used to detect some obvious bugs, but does not work across compilation boundaries. The better approach in my view is to insert runtime code which performs some tests (at least this how C# works).

I think it is understood that any compile time checking must be conservative in the general case to be sound. The same is true for compile time type checking, which must reject type safe code that can only be determined type safe at runtime.

Adding runtime checks does sound reasonable, and D already does this for array bounds.

On Wednesday, 29 August 2018 at 13:53:42 UTC, Nicholas Wilson wrote:
> On Wednesday, 29 August 2018 at 08:35:30 UTC, Walter Bright wrote:
>> On 8/28/2018 10:18 PM, Nicholas Wilson wrote:
>>> Bugzilla is not documentation. These are language changes they need to be in release notes and the spec.
>>
>> You asked for a clue: "we have no clue WTF its supposed to do or why the changes are being made" and there it is. There are no barriers to reviewing the idea nor the implementation.
>
> I don't know how much more blunt I can be while still being professional about it:
> _this must be documented properly_. This is not just about us reviewing it, this is also about people using it.

I can confirm that, from a user's perspective, (the state of) DIP1000 is not clearly defined. I read the forums so I know Phobos is not completely compatible yet, but I don't know what that means to me. The documentation for -dip1000 [1] simply refers to the DIP text, and after reading that I decide I want it. Then, possibly a while after switching to it, I start getting (mangled) link errors. It is not obvious to me that these relate to -dip1000 (which means wasting some time in trouble shooting) but they disappear after I take away that option. I would have appreciated if [1] would have included or linked to information on the situations in which you can successfully use -dip1000, and what are the symptoms when you move outside that envelope (link errors, presumably). At the very least, [1] could/should stress that -dip switches enable experimental functionality and that certain things are known to not work.

I do seem to be able to use -dip25 without issues though.

[1] https://dlang.org/dmd-windows.html

On Wednesday, 29 August 2018 at 05:01:14 UTC, Walter Bright wrote:
> On 8/25/2018 5:42 AM, Chris M. wrote:
>> What about my other point then on the syntax? I think something similar to what I suggested would be a much more flexible solution and is worth considering.
>
> Much more work would be needed to make that a proposal.

Here's some more details that could help with considering it incase you didn't see it:

https://forum.dlang.org/post/uxloaftaptfbzhbhquez@forum.dlang.org

Seems like it's a super set of return and the current proposal to (from what I can understand at least) make some parameters act like a sink in some situations when a function's return value is of a specific type and the parameters are annotated with some convention?

Cheers,
- Ali