On Wednesday, 21 March 2018 at 00:12:43 UTC, Mike Parker wrote:
As it stands, this DIP [1] is currently the candidate to become
DIP 1013. Any an all feedback for Draft Review is welcome.
Please read the intent [2] behind the Draft Review before
participating. Thanks!
[1] https://github.com/dlang/DIPs/pull/105
[2]
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#draft-review
Low hanging fruit:
IMO, the abstract is not right. This may differ between
institutions, but the way I was taught to write abstracts is that
they should be a condensed summary of what your document is
about. Think of it as an overview so someone can quickly read it
to get an idea of what you'll be talking about through the rest
of the document.
It is currently not possible to attach attributes to both enums
and function parameters
Again, probably a matter of taste, but I think this reads better
as "...not possible to attach attributes to enums _or_ function
parameters..."
Attributes and user-defined attributes (UDA) serve as a means
to provide extra meta data
I believe it's usually written "metadata", as one word. See this
from Google Books' Ngram viewer:
https://books.google.com/ngrams/graph?content=meta+data%2Cmetadata&case_insensitive=on&year_start=1965&year_end=2000&corpus=15&smoothing=3&share=&direct_url=t4%3B%2Cmeta%20data%3B%2Cc0%3B%2Cs0%3B%3Bmeta%20data%3B%2Cc0%3B%3BMeta%20Data%3B%2Cc0%3B%3BMeta%20data%3B%2Cc0%3B%3BMETA%20DATA%3B%2Cc0%3B.t4%3B%2Cmetadata%3B%2Cc0%3B%2Cs0%3B%3Bmetadata%3B%2Cc0%3B%3BMetadata%3B%2Cc0%3B%3BMETADATA%3B%2Cc0
What can be said for why attributes were included as a feature
in D can also be said for why they should be extended to enums
and function parameters.
This sentence reads very awkwardly.
It is benefitial to provide extra meta data about a symbol that
can be used at compile-time.
You assert this but don't provide any logical argument or
examples of why it's useful (yes, I know you have examples below).
Most of the framework for attributes already exist and it would
just be...
Should be "most of the framework for attributes already
_exists_". Also, it's more a matter of personal taste, but I
would suggest an Oxford comma between "exist" and "and" in that
sentence.
Allow additional meta information (attributes) to be attached
with enums and functions parameters
Should be "...to be attached _to_ enums and _function_
parameters..."
...and it would just be a matter of extending that into the
respective symbols...
I think that this should be "to" as opposed to "into".
A current solution for applying an UDA...
Should be "_a_ UDA".
A solution for applying the deprecation attribute to an enum
member can be done by
reimplementing an enum as a structure with static enums. This
allows the attribute to be
placed with the desired enum member. While still allowing for
any existing code that
simply used an enum before hand to still work accordingly, as
if the struct was an enum.
enum SomeEnumImpl
{
none = -1,
actualValue2 = 2,
actualValue3 = 3,
}
struct SomeEnum
{
SomeEnumImpl x;
alias this x;
deprecated("reason for deprecation")
static enum deprecatedValue0 = none;
deprecated("reason for deprecation")
static enum deprecatedValue1 = none;
}
AFAIK `static` on an enum does nothing. Also, `enum
deprecatedValue0 = none` should qualify `none`, i.e.,
`SomeEnumImpl.none`.
Allowing to deprecate enums which should not be used anymore as
seen here:
This language is sloppy. It could be better written as
"Deperecating individual enum values" or something similar. Also,
this is just a copy&paste of the same example from the "Existing
Solutions" section; I don't think the whole bit with creating a
struct with enum members, etc. really needs to be repeated.
All of these examples except the first seem to rely on function
parameter attributes being accessible outside that function. If I
recall correctly, this caused some controversy in past discussion
which must be addressed in this DIP.
