DIP 1012--Attributes--Preliminary Review Round 1

[Nicholas Wilson via Digitalmars-d]

On Monday, 31 July 2017 at 19:27:46 UTC, Jesse Phillips wrote:
> On Friday, 28 July 2017 at 23:25:35 UTC, Nicholas Wilson wrote:
>> On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
>>> * Remove the whole program defaults, I'm ok with it being 
>>> changed in a re-implementation of the runtime (like the 
>>> embedded example), we just don't need the extra confusion 
>>> within user code.
>>
>> The program defaults are there to make @safe by default a 
>> thing, and betterC by default a thing, which are covered in 
>> the _three Primary points_ of the semesters Vision 
>> document[1]. These would not normally be set (i.e. opt in).
>
> I read that as more, Improve Druntime and phobos's us of @safe 
> so that it becomes more usable.

Improving druntime and phobos is obviously important, but so is 
the ability for the end user to use it. If its hard to use less 
people will use it, conversely the easier it is the more likely 
people are to use it. Not that this also provides an easy way to 
find out which function are not @safe and fix them, without 
slapping @safe on main, i.e. build unit (package/library) at a 
time.

>>> * Specifying inferred needs to be within druntime only, and 
>>> thus may not need to exist.
>>
>> I think there is usefulness in having it, particularly as the 
>> meta-default (defaultAttributeSet). Walter has ben pushing for 
>> some time to infer attributes by default. This would provide a 
>> directive for the compiler to do so. Please elaborate.
>
> I don't expect inference to happen outside templates. Besides 
> if the compiler infers the appropriate attributes by default, 
> isn't 1. a default attribute redundant and 2. specifying 
> inference redundant as the compiler defaults to inferring?

It happens already for dip1000 IIRC and I be surprised if, 
particularly for @safe, Walter didn't want more inference. 
Especially for minimal user effort.

>>> The compiler will default functions to the first value of the 
>>> enum [for my example].
>>
>> ( That would provide a pessimistic default and debates the 
>> ability for the compiler to infer)
>
> Yes, just throwing in an example structure and why I mentioned 
> [for my example]. But as said earlier infer and default are at 
> odds.

I disagree. Even if infer wasn't the default I would certainly 
like to be able to have them be inferred at the flick of a 
compiler switch. It goes back to the ease of use argument, its 
more effort for me to manually annotate things.