DConf 2013 keynote

[Diggory]

>
> I didn't say an IDE was bad for D, I only said that if you need 
> an IDE to generate boilerplate for you, then there's something 
> wrong with the language.
>
> IDE's have lots of other valuable uses.

There is one case of generating boilerplate code which can hardly 
be avoided and would at least partially solve a problem that 
keeps coming up in one form or another:

For every new language feature that uses some form of attributes 
(ie. almost all of them) there is the problem of how 
automatically the attributes are applied, generally with these 
possibilities:

- The attribute is a purely internal concept used and deduced by 
the compiler. This has the problem that unless these attributes 
are in some way stored in the .di file the compiler has now way 
to determine them when it cannot see the code. It also leaks 
implementation details into the interface.

- The attribute is explicitly defined but inferred in some cases 
by the compiler.
This has the problem that it's now not obvious whether the 
attribute can be inferred or not, there are more rules to know 
about when automatic deduction is done, and there will still be 
many cases where the attributes cannot be safely inferred without 
leaking implementation detail, but the programmer forgets to add 
them.

- The attribute is explicitly defined but is inferred when "auto" 
is present.
This has the problem that there's no good way to finely tune 
which attributes "auto" should infer, and no way to un-set 
attributes. When "auto" is used on methods for use by external 
code it is again leaking implementation detail.

None of these are very satisfactory. A good solution should make 
it clear to the programmer which attributes are applied, make it 
easy to apply all the attributes which can be inferred but also 
easy to then change them, and not change when the implementation 
changes.

An IDE command which automatically infers all the attributes 
would seem to be the only way to solve this well. Unfortunately 
it doesn't exist yet... Anyway it would be worthwhile deciding on 
a consistent way to handle attributes as the number of them 
increase, and it would be worth making sure that whatever way is 
chosen is compatible with such a potential IDE feature.

Another option would be to add an attribute called "default" or 
something like that, and have the compiler issue a message if it 
finds a function with no attributes that tells the programmer 
what attributes the function COULD have so it's a reminder to 
either add them, or put "default" after it.