On Thu, Dec 04, 2014 at 04:33:22PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/4/2014 3:54 PM, H. S. Teoh via Digitalmars-d wrote:
> >>The compiler assumes func(s) returns a ref to s, and so it won't allow
> >>func(s) to be returned from foo().
> >
> >Ah, I see. So you're saying that under this DIP, `return func(...);`
> >from a ref function will be prohibited unless the arguments to func()
> >were all either scope or non-reference?
> 
> Right.
> 
> >That sounds good, though it *is* pretty invasive, as any existing ref functions that do this will need to be revised, which potentially spreads 'scope' to many other places, depending on how deeply the chain of tail recursion / tail func calls go.
> 
> I know:
> 
> 1. that's why the extensive support for scope inference
> 2. I couldn't see any other way

I'm not saying it's necessary a bad thing... just that it will be an invasive change that we should be prepared to deal with.


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 nicest of all possible ways. -- Larry Wall

On Thu, 04 Dec 2014 12:55:34 +0000
bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> This seems acceptable only if the compiler switch "-scope" implies functions to be @safe by default and @system on request, because currently lot of D programmers don't apply annotations like @safe to their D code. Opt-in safety doesn't work well (and in D we still have the problems caused by null pointers and references).
actually, for me explicit attributes doesn't work well at all. and D compiler can't infer atributes for functions (ok, it can, but it can't apply that without changing function signature). that's why alot of my code compiles awfully slow with separate compilation: i'm used to write argument-less templates everywhere, so compiler can infer and apply attributes by itself. i even stopped commenting that practice, 'cause it means that much of the code will carry comments like this:

  // template to allow attribute inference
  void foo() (A a, int c) { ... }


i think that something is very wrong with the function attributes. but i still can't think out how to improve that. but it still feels wrong.

that's not about "D designers made a mistake", that's about "i want to invent a better thing!" ;-)

On Fri, Dec 05, 2014 at 03:16:36AM +0200, ketmar via Digitalmars-d wrote:
> On Thu, 04 Dec 2014 12:55:34 +0000
> bearophile via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 
> > This seems acceptable only if the compiler switch "-scope" implies functions to be @safe by default and @system on request, because currently lot of D programmers don't apply annotations like @safe to their D code. Opt-in safety doesn't work well (and in D we still have the problems caused by null pointers and references).
>
> actually, for me explicit attributes doesn't work well at all. and D compiler can't infer atributes for functions (ok, it can, but it can't apply that without changing function signature). that's why alot of my code compiles awfully slow with separate compilation: i'm used to write argument-less templates everywhere, so compiler can infer and apply attributes by itself. i even stopped commenting that practice, 'cause it means that much of the code will carry comments like this:
> 
>   // template to allow attribute inference
>   void foo() (A a, int c) { ... }

I've been considering to start adopting that practice too.


> i think that something is very wrong with the function attributes. but i still can't think out how to improve that. but it still feels wrong.
> 
> that's not about "D designers made a mistake", that's about "i want to invent a better thing!" ;-)

In an ideal world, programmers would never have to know attributes even existed, the compiler would infer everything and optimize based on that.

However, we're not quite there yet. :-) (And I don't know when we'll ever get there. Maybe D3. But we probably won't see that in the next 10 years... probably more.)

I've often pondered about the possibility of a language where the compiler will analyze each module and infer any number of attributes and optimization opportunities for each symbol exported by that module, and this information will be saved in the object file (or some other kind of interfacing file). This includes any half-compiled template bodies and whatever else that can't be fully codegen'd until actual use.  The attributes will include all sorts of stuff that programmers normally wouldn't want to deal with -- there could be 10+ or 50+ attributes representing various optimization / static checking opportunities.  Then every time a module is imported by another module, the compiler never goes to the source code of the imported module anymore, but it will read the object (interface) file, which is fully attributed, and the saved attributes will be used internally for static checking, optimization, and inferring attributes for the current module.

This way, the programmer not only gets the benefit of attributes without actually having to explicitly use them, but the language designers can also add many more attributes than you'd ever want to manually type out, or even remove old attributes that are no longer useful. The interface files will also serve as a convenient (and superior) substitute for .di files (uuugly) or .h files (even worse).


T

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

On Thu, 4 Dec 2014 18:10:18 -0800
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> This way, the programmer not only gets the benefit of attributes without actually having to explicitly use them, but the language designers can also add many more attributes than you'd ever want to manually type out, or even remove old attributes that are no longer useful. The interface files will also serve as a convenient (and superior) substitute for .di files (uuugly) or .h files (even worse).
and those interface files will ease creation of my pet project: dynamic component framework a-la BlackBox Component Builder. i'm already thinking about exporting semi-processed ASTs as ".mda" files, so i can write tools that bypasses parsing and checking phases. such files can be used as module interfaces, as syntax completion databases and so on. they can even be processed with some bytecode generator to improve CTFE.

yet my project plan is to release pre-alpha version not sooner than in 2030, so i'm not really working on it with full speed. ;-)

On 12/4/2014 4:48 PM, H. S. Teoh via Digitalmars-d wrote:
>  Well, the "Expressions" section defines certain lifetimes to be
> infinity, however, it contradicts the definition of an rvalue's lifetime
> given under "Definitions" - "Lifetime", which states that an rvalue's
> lifetime lasts only to the end of the statement. This would imply that
> the following ought to be rejected:
>
> 	int x = 1 + 2; // lifetime(1 + 2) = end of statement
> 			// but lifetime(x) = infinity
>
> Sounds like the Definitions section is not precise enough. :-)

An 'int' is not a view!

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.2709.1417745546.9932.digitalmars-d@puremagic.com...

> I've often pondered about the possibility of a language where the
> compiler will analyze each module and infer any number of attributes and
> optimization opportunities for each symbol exported by that module, and
> this information will be saved in the object file (or some other kind of
> interfacing file). This includes any half-compiled template bodies and
> whatever else that can't be fully codegen'd until actual use.  The
> attributes will include all sorts of stuff that programmers normally
> wouldn't want to deal with -- there could be 10+ or 50+ attributes
> representing various optimization / static checking opportunities.  Then
> every time a module is imported by another module, the compiler never
> goes to the source code of the imported module anymore, but it will read
> the object (interface) file, which is fully attributed, and the saved
> attributes will be used internally for static checking, optimization,
> and inferring attributes for the current module.

This can't be used to infer attributes that can produce errors - those attributes have to be user-visible or the errors don't make any sense.  If it's purely for optimization, then that's basically what LTO does. 

On Friday, 5 December 2014 at 00:32:32 UTC, Walter Bright wrote:
> On 12/4/2014 3:04 PM, deadalnix wrote:
>> So as mentioned, there are various problem with this DIP :
>>  - rvalue are defined as having a scope that goes to the end of the statement.
>> That mean they can never be assigned to anything as per spec.
>
> I don't believe this is correct. Rvalues can be assigned, just like:
>
>    __gshared int x;
>    { int i; x = i; }
>
> i's scope ends at the } but it can still be assigned to x.
>

It work even better when i has indirections.

>>  - It add more special casing with & (as if it wasn't enough of a mess with
>> @property, optional () and the fact the function aren't first class). For
>> instance *e has infinite lifetime when &(*e) is lifetime(e).
>
> That's right. I know you're worried about that, but I still don't see it as an actual problem. (The optimizer makes use of this special case all the time.)
>

Yes, this is the job of the optimizer to do this kind of stunt.
Not the semantic analysis.

>> Also, considering *e has infinite lifetime, (but not e[i] ???)
>
> e[i] should be same as *e, unless e is a literal or tuple.
>

Ho I missed the *. Sorry for that.

>> what is the point of scope at all ? If all indirection goes to infinite lifetime (ie GC) then
>> lifetime only apply to local variable and it should not be able to escape these,
>> scope or not.
>
> I originally had scope only apply to ref, but that made having scoped classes impossible.
>

Promoting scoped class on stack is an ownership problem, and out
of scope (!). It make sense to allow it as an optimization.

Problem is, lifetime goes to infinite after indirection, so I'm
not sure what the guarantee is.

>
>> During discussion, I proposed to differentiate lifetime calculation between
>> lvalues and rvalues (which are inherently different beasts with different
>> lifetime) and carry (or not) the scope flag with each expression.
>
> I'm not sure how that would be different from the DIP as it stands now.

I cause everything reached through the view to be scope and
obliviate the need for things like &(*e) having special meaning.

On 12/4/2014 2:08 PM, bearophile wrote:
> Perhaps you can't leave the "@safe on default" issue out of the DIP69. Currently
> most D code I see around is not tagged with @safe. If people don't bother
> applying that annotation, all the work you will do to implement DIP69 will be
> wasted or partially wasted.

The attributes don't have much use for small programs. When a program is small enough that one person can keep it all in their head, there is not much use for it. I'd like to keep D usable for quick small program writing.

Attributes become more and more useful the larger the program gets, and the more people are working on it. In such cases, I don't think it's near as much of a burden to put in a few annotations, and the payoff is significantly larger.


> I and other people have opened several bug reports on @safe, some of them are
> (but others are present, this is a subset):
>
> https://issues.dlang.org/show_bug.cgi?id=13615
> https://issues.dlang.org/show_bug.cgi?id=13681
> https://issues.dlang.org/show_bug.cgi?id=12948
> https://issues.dlang.org/show_bug.cgi?id=13607
> https://issues.dlang.org/show_bug.cgi?id=12845
> https://issues.dlang.org/show_bug.cgi?id=6646
> https://issues.dlang.org/show_bug.cgi?id=11176
> https://issues.dlang.org/show_bug.cgi?id=6333
> https://issues.dlang.org/show_bug.cgi?id=13054
> https://issues.dlang.org/show_bug.cgi?id=13506
> https://issues.dlang.org/show_bug.cgi?id=13188

Thanks you.

On 12/4/2014 1:56 PM, H. S. Teoh via Digitalmars-d wrote:
> FYI: https://issues.dlang.org/show_bug.cgi?id=13671

Ok, ok, I fixed the DIP :-)

> void foo(int[2]) {}
> void bar(int[]) {}
> void main() @nogc {
>     foo([1, 2]s);
>     bar([1, 2]s);
> }

That is a rather unfriendly syntax, it is the kind that degenerates into noise with other structures.