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.