On 3/22/15 10:20 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Sunday, 15 March 2015 at 14:10:02 UTC, Marc Schütz wrote:
>> Here's the new version of my scope proposal:
>> http://wiki.dlang.org/User:Schuetzm/scope2
>>
>> It's still missing real-life examples, a section on the
>> implementation, and a more formal specification, as well as a
>> discussion of backwards compatibility. But I thought I'd show what I
>> have, so that it can be discussed early on.
>>
>> I hope it will be more digestible for Walter & Andrei. It's more or
>> less an extended version of DIP25, and avoids the need for most
>> explicit annotations.
>
> BUMP
>
> @Walter & Andrei: What is your opinion? Is it better than the last
> proposal? Worse? Good enough?

Speaking for myself (though I suspect Walter is in a similar position) I'm not sure when I'll have time to get to it. I'm to my head in stuff that's important and urgent.

I need to get DConf submissions reviewed and published. (That should happen later today - stay tuned!) What seems to be a trivial process for anyone who hasn't done it turns out to be a ton of grind.

At work I'm working on reviewing a bunch of non-idiomatic D (rather Java/Python/Go written in D) and refactor it into much shorter and more efficient idiomatic D. That is also important and urgent; with badly written D there's little visible advantage to D at large and a lot of incentive to fall back on the more familiar languages. That spills into documentation work, and recent discussions between Walter and me led to him (and thankfully others) being preoccupied with improving the documentation.

As odd as it sounds, better documentation for what we have is more "important * urgent" cross-product than exploration of language improvements.

Then I also need to get diverted into PR work like improving byLine. Something that has not really been internalized by folks here is that statistically EVERYBODY is on StackOverflow and NOBODY is on forum.dlang.org. Clearly the few folks in this forum are quite influential in the technical direction of the language, but the long-term pull (upwards or downward) of people influenced by articles like http://stackoverflow.com/questions/28922323/improving-line-wise-i-o-operations-in-d/29153508 can turn things radically better (or respectively worse). On that page there is one relevant piece of information - the link to the PR I created. It has just one vote, which pretty much means that next to nobody in this forum bothered to muster even that level of participation.

I can't express how much relief there is that Adam's weekly newsletter and Martin's work on the release mean that essentially I can take such matters off my mind.

Above all, my main preoccupation is to convert the energy going in incessant conversations in this forum on a variety of topics, from Brownian motion into directed propelling force.

===

A good trait of a graduate student is being able to act creatively on little advisor input. Academic advisors at top universities are almost always exceptionally good in their field; incredibly troves of insight and information. However, they are also immensely - and proverbially - busy which means they have little time to dedicate to any particular tidbit of information. For graduate students, that means if a particular matter reached the consciousness level of the adviser, it should definitely be looked into without further prodding. I sometimes wish D's leadership were in that position - if there is agreement some matter is important, it would be naturally looked into without a need to insist on it or debate it at nauseam.

Your proposal? I want to look into it. I must look into it, and it's a requirement that I look into it in order for it to make it into D. But I cannot promise when for as long as I am unable to delegate even the most trivial matters.


Andrei

On 3/22/15 12:29 PM, Andrei Alexandrescu wrote:
> Then I also need to get diverted into PR work like improving byLine.

Here "PR" stands for "Public Relations". -- Andrei

On 3/15/2015 7:10 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> Here's the new version of my scope proposal:
> http://wiki.dlang.org/User:Schuetzm/scope2
>
> It's still missing real-life examples, a section on the implementation, and a
> more formal specification, as well as a discussion of backwards compatibility.
> But I thought I'd show what I have, so that it can be discussed early on.
>
> I hope it will be more digestible for Walter & Andrei. It's more or less an
> extended version of DIP25, and avoids the need for most explicit annotations.

Thanks for doing this. It is a good step forward.

Consider the code:

  struct Foo { C obj; }
  @safe void bar(C c, Foo* f) { f.obj = c; }

Under the proposal, for @safe code, this would have to be written as:

  @safe void bar(static C c, Foo* f) ...

I'm concerned this may break an astonishing amount of code.

On Tuesday, 31 March 2015 at 20:07:19 UTC, Walter Bright wrote:
> Consider the code:
>
>   struct Foo { C obj; }
>   @safe void bar(C c, Foo* f) { f.obj = c; }
>
> Under the proposal, for @safe code, this would have to be written as:
>
>   @safe void bar(static C c, Foo* f) ...
>

Either that, or:

    @safe void bar(C c return!f, Foo* f) ...

or:

    @safe void bar()(C c, Foo* f) ...

> I'm concerned this may break an astonishing amount of code.

We could go a step further and infer scope for all @safe functions, except those with at least one explicit annotation. This would be almost backward compatible, except for the fact that some arguments then suddenly become scope and therefore the mangling changes.

On 4/1/2015 10:00 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> On Tuesday, 31 March 2015 at 20:07:19 UTC, Walter Bright wrote:
>> Consider the code:
>>
>>   struct Foo { C obj; }
>>   @safe void bar(C c, Foo* f) { f.obj = c; }
>>
>> Under the proposal, for @safe code, this would have to be written as:
>>
>>   @safe void bar(static C c, Foo* f) ...
>>
>
> Either that, or:
>
>      @safe void bar(C c return!f, Foo* f) ...
>
> or:
>
>      @safe void bar()(C c, Foo* f) ...
>
>> I'm concerned this may break an astonishing amount of code.
>
> We could go a step further and infer scope for all @safe functions, except those
> with at least one explicit annotation. This would be almost backward compatible,
> except for the fact that some arguments then suddenly become scope and therefore
> the mangling changes.

The problem with inferring attributes on non-template functions is the source must be available to the compiler. That's obviously true for templates, but not so true for non-templates, where only the signature is available.

I'm thinking of a modest step which would be a subset of your proposal:

1. implement 'scope' and 'return' for arrays, classes, and pointers
2. implement inference for templates and lambdas
3. enable it with the -dip25 switch

and see how far that takes us.

Walter Bright:

> I'm thinking of a modest step which would be a subset of your proposal:
>
> 1. implement 'scope' and 'return' for arrays, classes, and pointers
> 2. implement inference for templates and lambdas
> 3. enable it with the -dip25 switch
>
> and see how far that takes us.

This is interesting. For the final D programmer what's the practical difference between your proposed subset compared to the full proposal?

Bye,
bearophile

On 2015-04-01 22:26, Walter Bright wrote:

> The problem with inferring attributes on non-template functions is the
> source must be available to the compiler. That's obviously true for
> templates, but not so true for non-templates, where only the signature
> is available.

In my experience with D, the source code for most the functions are available. Everyone is doing open source and no one bother with writing/generating .di files. Not implementing attribute inference for non-template functions just because the source code of _some_ functions might not be present is not a good reason. Why should the non-template functions that _have_ the source code available suffer?

-- 
/Jacob Carlborg

On 4/1/15 11:45 PM, Jacob Carlborg wrote:
> On 2015-04-01 22:26, Walter Bright wrote:
>
>> The problem with inferring attributes on non-template functions is the
>> source must be available to the compiler. That's obviously true for
>> templates, but not so true for non-templates, where only the signature
>> is available.
>
> In my experience with D, the source code for most the functions are
> available. Everyone is doing open source and no one bother with
> writing/generating .di files. Not implementing attribute inference for
> non-template functions just because the source code of _some_ functions
> might not be present is not a good reason. Why should the non-template
> functions that _have_ the source code available suffer?

Because large projects. -- Andrei

On Thu, 02 Apr 2015 08:45:10 +0200, Jacob Carlborg wrote:

> Why should the non-template
> functions that _have_ the source code available suffer?

'cause inferring attributes requires running full semantic analysis on the code, so each imported function *must* be fully processed. and with explicit attributes it's enough to parse it and setup signature types.

On Thu, 02 Apr 2015 06:59:40 +0000, ketmar wrote:

> On Thu, 02 Apr 2015 08:45:10 +0200, Jacob Carlborg wrote:
> 
>> Why should the non-template functions that _have_ the source code available suffer?
> 
> 'cause inferring attributes requires running full semantic analysis on the code, so each imported function *must* be fully processed. and with explicit attributes it's enough to parse it and setup signature types.

p.s. you can always fix your code instead, turning your functions to argless templates.