On Fri, Oct 18, 2013 at 06:34:07PM +0200, Paulo Pinto wrote:
> Am 18.10.2013 17:40, schrieb Andrei Alexandrescu:
> >On 10/17/13 11:53 PM, Maxim Fomin wrote:
> >>...
> >
> >It's a given that safety will disallow constructs that are safe upon inspection but the type system is unable to prove correct. This is the case for all languages, C# included.
> >
> >
> >Andrei
> >
> 
> 
> Wouldn't be easier, if D followed a model similar to C# and Modula-3 where the code is by default safe and system/trusted code is only allowed inside explicitly unsafe code blocks?
> 
> Just an idea, maybe it wouldn't be much different from what it is now.
[...]

It would break existing code.

But if we're gonna do it, I say we should go all the way: make @safe, pure, and nothrow default, and require annotations only for @system, impure, throwing. If we advertise D as "do the right thing by default, but allow the user to override it if necessary", then we should make all code @safe, pure, and nothrow by default. (Well, at the very least @safe and pure, I'm not as sure about making nothrow default. But it would be nice for those performance-conscious people who don't like the fact that throwing functions require extra stack frame setup, which thus impacts performance.)


T

-- 
One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion

On Friday, 18 October 2013 at 17:06:57 UTC, H. S. Teoh wrote:
> But if we're gonna do it, I say we should go all the way:

And make scope the default parameter thingy, and implement it.

God I want some kind of escaping check thing so badly, it is supposed to work already!

http://dlang.org/function.html
scope: references in the parameter cannot be escaped (e.g. assigned to a global variable)


But what's interesting here is that references to immutable are virtually value types; string, or immutable(int)[] *can* be escaped safely, whereas const(int)[] or int[] might not, they can be overwritten elsewhere (the case now) and can also be freed elsewhere (if you don't use the gc on them). An immutable reference would necessarily use the gc, since otherwise it isn't really immutable.

So you can store immutable stuff in a global or anything and that's perfectly ok, so scope immutable == immutable. scope const is different though.

> I'm not as sure about making nothrow default.

i think throwing is really the default anyway just writing normal D. If we sampled 100 random D functions, I think we'd find most of them are @safe in practice, even if not marked, and probably throw too. So that'd be the sane default.

On Friday, 18 October 2013 at 17:19:17 UTC, Adam D. Ruppe wrote:
> On Friday, 18 October 2013 at 17:06:57 UTC, H. S. Teoh wrote:
>> But if we're gonna do it, I say we should go all the way:
>
> And make scope the default parameter thingy, and implement it.
>
> God I want some kind of escaping check thing so badly, it is supposed to work already!

Yeah it is astonishing how many holes in type system implementing that single small thing can fix. I wish it never was in documentation, that way I would not have bothered me that much at least :)

On Fri, Oct 18, 2013 at 07:19:16PM +0200, Adam D. Ruppe wrote:
> On Friday, 18 October 2013 at 17:06:57 UTC, H. S. Teoh wrote:
> >But if we're gonna do it, I say we should go all the way:
> 
> And make scope the default parameter thingy, and implement it.
> 
> God I want some kind of escaping check thing so badly, it is supposed to work already!

+1. I'm waiting for scope to be implemented too.

@Walter: Just out of curiosity, what exactly is holding up the implementation of scope? AFAICT, a relatively simple one-pass flow analysis would do the job; am I missing something obvious?


> http://dlang.org/function.html
> scope: references in the parameter cannot be escaped (e.g. assigned to
> a global variable)
> 
> 
> But what's interesting here is that references to immutable are
> virtually value types; string, or immutable(int)[] *can* be escaped
> safely, whereas const(int)[] or int[] might not, they can be
> overwritten elsewhere (the case now) and can also be freed elsewhere
> (if you don't use the gc on them). An immutable reference would
> necessarily use the gc, since otherwise it isn't really immutable.
> 
> So you can store immutable stuff in a global or anything and that's perfectly ok, so scope immutable == immutable. scope const is different though.

Interesting.

Though I'm still unclear about the meaning of a scope delegate (its *intended* meaning, that is, not necessarily its current implementation).


> >I'm not as sure about making nothrow default.
> 
> i think throwing is really the default anyway just writing normal D. If we sampled 100 random D functions, I think we'd find most of them are @safe in practice, even if not marked, and probably throw too. So that'd be the sane default.

True, most "normal" D code would allow throwing exceptions, since that's a core language feature, so nothrow shouldn't be default. But pure and @safe *should* be default IMO.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicests of all possible ways. -- Larry Wall

On Fri, Oct 18, 2013 at 07:25:03PM +0200, Dicebot wrote:
> On Friday, 18 October 2013 at 17:19:17 UTC, Adam D. Ruppe wrote:
> >On Friday, 18 October 2013 at 17:06:57 UTC, H. S. Teoh wrote:
> >>But if we're gonna do it, I say we should go all the way:
> >
> >And make scope the default parameter thingy, and implement it.
> >
> >God I want some kind of escaping check thing so badly, it is supposed to work already!
> 
> Yeah it is astonishing how many holes in type system implementing that single small thing can fix. I wish it never was in documentation, that way I would not have bothered me that much at least :)

So what's the hold up? Just the lack of manpower to actually implement it?

I wish there were a time store I could buy more spare time from so that I could actually work on D stuff on top of all the other stuff I'm busy with...


T

-- 
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan

On Friday, October 18, 2013 10:31:55 H. S. Teoh wrote:
> On Fri, Oct 18, 2013 at 07:25:03PM +0200, Dicebot wrote:
> > On Friday, 18 October 2013 at 17:19:17 UTC, Adam D. Ruppe wrote:
> > >On Friday, 18 October 2013 at 17:06:57 UTC, H. S. Teoh wrote:
> > >>But if we're gonna do it, I say we should go all the way:
> > >And make scope the default parameter thingy, and implement it.
> > >
> > >God I want some kind of escaping check thing so badly, it is supposed to work already!
> > 
> > Yeah it is astonishing how many holes in type system implementing that single small thing can fix. I wish it never was in documentation, that way I would not have bothered me that much at least :)
> 
> So what's the hold up? Just the lack of manpower to actually implement it?

The facts that escape analysis tends to be difficult and that Walter generally refuses to do anything in the compiler which involves flow analysis would tend to make scope very difficult to implement properly. I don't know that Walter has any plans with regards to scope at this point or not. At the moment, it seems to be relegated to delegates only, and even there, it's not fully implemented. AFAIK, no plans beyond that for scope have ever been announced. It's just that the way that it's defined in the spec implies that it would work with any reference type.

- Jonathan M Davis

On Friday, October 18, 2013 10:05:39 H. S. Teoh wrote:
> It would break existing code.
> 
> But if we're gonna do it, I say we should go all the way: make @safe, pure, and nothrow default, and require annotations only for @system, impure, throwing. If we advertise D as "do the right thing by default, but allow the user to override it if necessary", then we should make all code @safe, pure, and nothrow by default. (Well, at the very least @safe and pure, I'm not as sure about making nothrow default. But it would be nice for those performance-conscious people who don't like the fact that throwing functions require extra stack frame setup, which thus impacts performance.)

Yeah, if we could go back, it would be great to do something like that, but I think that it's pretty clear that it would be too much of a breaking change at this point.

- Jonathan M Davis

On Fri, Oct 18, 2013 at 01:38:12PM -0400, Jonathan M Davis wrote:
> On Friday, October 18, 2013 10:31:55 H. S. Teoh wrote:
> > On Fri, Oct 18, 2013 at 07:25:03PM +0200, Dicebot wrote:
> > > On Friday, 18 October 2013 at 17:19:17 UTC, Adam D. Ruppe wrote:
> > > >On Friday, 18 October 2013 at 17:06:57 UTC, H. S. Teoh wrote:
> > > >>But if we're gonna do it, I say we should go all the way:
> > > >And make scope the default parameter thingy, and implement it.
> > > >
> > > >God I want some kind of escaping check thing so badly, it is supposed to work already!
> > > 
> > > Yeah it is astonishing how many holes in type system implementing that single small thing can fix. I wish it never was in documentation, that way I would not have bothered me that much at least :)
> > 
> > So what's the hold up? Just the lack of manpower to actually implement it?
> 
> The facts that escape analysis tends to be difficult and that Walter generally refuses to do anything in the compiler which involves flow analysis would tend to make scope very difficult to implement properly.

What's the reason for refusing to implement flow analysis? Maybe I'm missing something obvious, but for the purposes of escape analysis, isn't it enough to just have a simple one-pass flow analysis? Do we really need full-scale flow analysis in order to do escape analysis?


> I don't know that Walter has any plans with regards to scope at this point or not. At the moment, it seems to be relegated to delegates only, and even there, it's not fully implemented.  AFAIK, no plans beyond that for scope have ever been announced. It's just that the way that it's defined in the spec implies that it would work with any reference type.
[...]

Well, then we should either change the spec, or make concrete plans on how to implement it. The current state of limbo that scope is only generates bad rep for D while offering nothing in return.


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.

On Friday, October 18, 2013 10:41:38 H. S. Teoh wrote:
> On Fri, Oct 18, 2013 at 01:38:12PM -0400, Jonathan M Davis wrote: What's the reason for refusing to implement flow analysis? Maybe I'm missing something obvious, but for the purposes of escape analysis, isn't it enough to just have a simple one-pass flow analysis? Do we really need full-scale flow analysis in order to do escape analysis?

I think that it's mainly a question of complexity. Walter doesn't want to add that kind of complexity to the compiler - especially when that means making the language requires it, because that makes writing tools for the language harder. Given his stance on flow analysis, I'm actually kind of surprised that scope ever made it into the language at all.

> > I don't know that Walter has any plans with regards to scope at this point or not. At the moment, it seems to be relegated to delegates only, and even there, it's not fully implemented. AFAIK, no plans beyond that for scope have ever been announced. It's just that the way that it's defined in the spec implies that it would work with any reference type.
> 
> [...]
> 
> Well, then we should either change the spec, or make concrete plans on how to implement it. The current state of limbo that scope is only generates bad rep for D while offering nothing in return.

scope's future definitely needs to be sorted out. I find the fact that compiles and is simply ignored when it's not valid particularly bad. And the fact that in is an alias for const scope is probably going to cause a lot of problems if/when scope is fully implemented because of how many people use in simply because they like how it seems like the opposite of out, but they don't take into account that the code in question won't work with scope.

- Jonathan M Davis

On 10/18/13 10:53 AM, Jonathan M Davis wrote:
> On Friday, October 18, 2013 10:41:38 H. S. Teoh wrote:
>> On Fri, Oct 18, 2013 at 01:38:12PM -0400, Jonathan M Davis wrote:
>> What's the reason for refusing to implement flow analysis? Maybe I'm
>> missing something obvious, but for the purposes of escape analysis,
>> isn't it enough to just have a simple one-pass flow analysis? Do we
>> really need full-scale flow analysis in order to do escape analysis?
>
> I think that it's mainly a question of complexity. Walter doesn't want to add
> that kind of complexity to the compiler - especially when that means making
> the language requires it, because that makes writing tools for the language
> harder. Given his stance on flow analysis, I'm actually kind of surprised that
> scope ever made it into the language at all.

I think one good compromise is to stick with the exact amount of flow control we currently have in constructors (which is primitive but quite adequate), and use that creatively. It's already implemented and works, so the implementation costs of applying it to other cases should be low.

Andrei