On Friday, 28 July 2017 at 21:47:32 UTC, Jesse Phillips wrote:
On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote:
DIP 1012 is titled "Attributes".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md
Thanks in advance to all who participate.
Destroy!
My primary points
* Don't formally deprecate the keywords, there is not enough
justification to ever remove them.
Indeed the only reason for removing them would be to remove code
from the compiler. They do no harm at all.
* 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).
* 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'm concerned user defined attributes could define a
"defaults" for functions.
you mean user UDAs (if not please explain)? the default
application of UDA is for core attributes only.
I think the updated document needs some additional rework, here
are some examples:
# Rational
A number of issues with the existing functional attribute
system have come up through the years.
* Certain attributes don't have a name, e.g. All functions
''throws'' but this is not an existing attribute.
* The default attributes were not correctly chosen, e.g. all
class methods should be ''final'' unless specified otherwise,
and because of the first point declaring 'final:' at the top of
the class cannot be undone.
* AliasSeq is provided to manage Attributes, but it doesn't
handle built in attributes (I could be wrong but is what I'm
getting from the document even though it isn't explicitly
stated)
* ...
# Description
Function existing attributes and their unnamed counterpart will
exist as an enum within core.attributes. This module will be
implicitly imported to provide the symbols without explicit
import or breaking existing code. The compiler will recognize
the non-@ based attributes as the corresponding core.attribute.
...
## Implementation Details
----------
module core.attribute;
enum Protection {
system,
safe,
trusted,
}
alias safe = Protection.safe;
...
-----------
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)
[So on and so forth]
Thanks for your suggestions.
[1]: https://wiki.dlang.org/Vision/2017H2
