On 8/17/2018 12:50 AM, Jonathan M Davis wrote:
> That particular bug is a duplicate of
> https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed
> based on the fact that -dip1000 fixes the problem by treating marking the
> slice of a static array with scope. It's still quite broken without -dip1000
> though.

D will never be @safe until -dip1000 is the default. However, I cannot get any traction with improving this:

https://github.com/dlang/dmd/pull/8504

blocks progress on getting Phobos to compile with -dip1000, and nobody will help me with it.


> Honestly, the reality of the matter is that @safe is probably always going
> to be somewhat broken, because it's implemented via blacklisting rather than
> whitelisting. Instead of @safe only allowing stuff that's been proven to be
> @safe, it disallows stuff that a programmer decided was @system. The bug you
> ran into is a pretty glaring one that arguably should have been fixed ages
> ago,

It was fixed with -dip1000 ages ago.


> but given how hard it is to prove what is and isn't @safe, there are
> bound to be corner cases which have been missed. As we find them, they'll be
> fixed, but who knows how many are left or whether we'll ever actually get
> them all.

The whitelisting idea has come up before. I see it, though, as a way to avoid dealing with the issues as nobody is willing to do any work at all on this approach. Furthermore, I see no evidence that whitelisting will produce superior results.

On the other hand, I see plenty of evidence that @safe bugs that are found and posted to bugzilla get fixed.

If people want to see @safe be watertight,

1. post any problems to bugzilla, and tag them with the 'safe' keyword.

2. investigate solutions to any issues tagged with 'safe' keyword.

3. review/approve PR 8504.

On 8/17/2018 3:01 AM, Jonathan M Davis wrote:
> we still don't have a real plan as to how we're going to make
> -dip1000 the default.
We do have a plan. Get Phobos to compile with -dip1000. As to why that hasn't happened yet, see:

https://github.com/dlang/dmd/pull/8504

On 8/17/2018 4:33 AM, Atila Neves wrote:
> I've been using -dip1000 a lot lately.

Great news!

> I hit two bugs yesterday.

In D? or in your code?

> When it works, it's great, _except_:
> 
> . @safe isn't default
> . -dip1000 isn't default
> . Good luck figuring out why your template functions aren't @safe and coaxing the compiler to tell you why it's inferring the attributes it is.

I empathize with that, having run into the same problem. A couple months ago I improved the resulting error messages, which make it a lot easier to track down why it is inferring what it does.

> Bonus points if it's a Phobos function so you can't slap `@safe` on its definition.

Sometimes I think it is better to just slap them with @safe and to hell with unsafe parameters. :-)

> Did I mention the bugs?

Bugs don't count if they're not in bugzilla!

On 8/17/2018 11:17 AM, bachmeier wrote:
> This is a good example of D needing to evolve or fizzle out. I don't see evidence that the community has yet figured out how to evolve the language. If it had, these problems would not be around for so many years.

We deprecate features of D all the time. (Remember the D1 => D2 wrenching change?)

The reason @safe cannot be default at the moment it because -dip1000 needs work, and nobody is willing to pitch in and review/pull my PRs on it.

On 8/17/2018 5:30 AM, Atila Neves wrote:
> It's not easy though. You have to either be building your own phobos

Not really. You only have to be able to import phobos files. You don't have to compile something that will link.

I.e. just copy the phobos source tree, add @safe to it, and point the compiler at that one.


> or sudo editing files in /usr/include. You can, but it's a pain. Then there's finding out exactly where in a chain of 10 template functions that it became @system...

I recently fixed the compiler to say which template overload was used. It's a huge time saver.

But you're currently doomed on this anyway, as an awful lot of Phobos winds up calling put(), which cannot be inferred as @safe without:

https://github.com/dlang/dmd/pull/8504

On Saturday, 18 August 2018 at 02:17:01 UTC, Walter Bright wrote:
> On 8/17/2018 4:33 AM, Atila Neves wrote:
>> I've been using -dip1000 a lot lately.
>
> Great news!

:)


>> I hit two bugs yesterday.
>
> In D? or in your code?

In dmd.

> Bugs don't count if they're not in bugzilla!

As mentioned in my other thread, I went to file one and it was declared not a bug:

https://issues.dlang.org/show_bug.cgi?id=17927

I don't know how that's possible given that supposedly @safe code is doing pretty bad things. That disheartened me enough to not continue although I did file this one:

https://issues.dlang.org/show_bug.cgi?id=19173

On 8/17/18 11:04 PM, Walter Bright wrote:
> On 8/17/2018 11:17 AM, bachmeier wrote:
>> This is a good example of D needing to evolve or fizzle out. I don't see evidence that the community has yet figured out how to evolve the language. If it had, these problems would not be around for so many years.
> 
> We deprecate features of D all the time. (Remember the D1 => D2 wrenching change?)

Hm... if you are going for "all the time", the example of D1 to D2 transition is pretty dated.

I'd say more like the addition of UDAs was a big evolution. Or maybe UFCS.

> The reason @safe cannot be default at the moment it because -dip1000 needs work, and nobody is willing to pitch in and review/pull my PRs on it.

I would, but I have no idea how dip1000 is supposed to work. I think only you understand it. Even looking at the PR that you have been citing over and over, I can't make heads or tails of what it does or what it allows.

-Steve

On Monday, August 20, 2018 7:46:48 AM MDT Steven Schveighoffer via Digitalmars-d wrote:
> I would, but I have no idea how dip1000 is supposed to work. I think only you understand it. Even looking at the PR that you have been citing over and over, I can't make heads or tails of what it does or what it allows.

The basic idea of DIP 1000 seems simple enough, but once you get into the details, it gets hard to understand fast.

And from what work I've done to make std.datetime work with it better, I'm very much inclined to think that it's just too intrusive for too little gain. I mean, it's great that you can know that a pointer isn't going to escape, but once you have to start marking up member functions all over the place just so that the type can work with scope? It just seems like it's too viral. I honestly do not understand why much of anything in std.datetime.systime needs scope, but I was forced to mark up SysTime all over the place in order for scope variables of type SysTime to work just because it contains a class reference - one which cannot posssibly ever be on the stack, since you can't pass a scope argument to a member function to have it then stored in a member variable. So, why it has any effect on why scope is required on member functions, I have no idea.

User-defined types can't contain anything that's scope (since that would mean that they escaped), and yet, they potentially have to be marked up with scope all over the place in case someone qualifies a variable of that type with scope somewhere. And of course, because of how stuff like ranges work, you're quickly in trouble if they're marked with scope, since then they can't be wrapped by other ranges, making them useless for pretty much anything other than foreach. scope seems great for toy examples or stuff that's extern(C), but once user-defined types get involved, it's a mess.

I've got partially completed changes to std.datetime.interval towards making it work with scope better that I need to get back to, but to be honest, the more I've tried to do anything with -dip1000, the less I've like it, and it's really hard to be motivated to go to the effort of making anything compatible with it.

- Jonathan M Davis

On 8/20/2018 6:08 AM, Atila Neves wrote:
> As mentioned in my other thread, I went to file one and it was declared not a bug:
> 
> https://issues.dlang.org/show_bug.cgi?id=17927

I'll look at it again.

On 8/20/2018 6:46 AM, Steven Schveighoffer wrote:
> I would, but I have no idea how dip1000 is supposed to work. I think only you understand it. Even looking at the PR that you have been citing over and over, I can't make heads or tails of what it does or what it allows.

The way to understand dip1000 is to forget about `this`, arrays, structs, classes, delegates, etc. Just think about pointers - functions that take pointers as arguments, and return pointers.

That simplifies things enormously.

Once that makes sense, then deconstruct the higher level constructs into pointers, and then you'll see how they work.

This is why my presentation does it all in terms of pointers:

    http://dconf.org/2017/talks/bright.html

If you're having trouble understanding a particular example, rewrite it in terms of pointers. If it still is inscrutable, then ask about the pointer version here.

(When someone gives me some complex thing and says "I don't understand scope here", I always first rewrite it in terms of pointers. It's the same thing I do with bug reports that use templates - I manually instantiate the templates first.)