DIP69 - Implement scope for escape proof references

[H. S. Teoh via Digitalmars-d]

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 at 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.