On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:
1) Add the opposite attributes: `impure`, `throws`, `@gc`, etc.
2) Add the module version thing that changes defaults on
request
3) imagine more potential going forward
I dislike doubling the keywords by having a 'not' case for each.
I'd rather have a systematic way of adding/removing attributes
and udas.
Something like:
@gc
@!gc (previously @nogc, compiler could even rewrite @nogc into
@!gc for transition)
---
Anyway, I think we could just have a compile time switch for
defaults.
Since some projects want to have pure, @safe, immutable by
default, but others want to have @system @nogc. And no one
wants write attributes more than they have to.
For example, I kind of like the current defaults since I like
flexibility/changeability/editability of code. Because that
makes coding fun which in turn usually means better code,
features and productivity. Strictness is just a kind of salt
that can be sprinkled on code in few difficult or dangerous
cases.
Also I think @safe is a little bit broken (because of @trusted
and even the very pros (d-devs) seem to get @trusted wrong on a
regular basis (at least that's my perception)). Just bite the
bullet and use Rust if you want to be actually safe.
I'm not a huge fan of immutable/const system either as it's
kind of difficult to use and low benefits. It often leads into
backtracking and changing your code all over the place (small
change becomes an avalanche), because you found out in the last
leaf function of your subsystem, that your design can't
actually be immutable (basically, you forgot or couldn't
imagine that elusive corner case no. 99).
The good thing is that immutable/const is actually strict and
checkable. No holes like in @safe.
So if this change would happen, I would probably start all of
my d files with
impure:
@system:
(@nogc:) // depending on my needs, I actually haven't had big
issues with the gc
(nothrow:)
...
Which reminds me that it would be nice to group attributes as
well.
Something like this:
alias @apiStrict = @safe immutable pure
int foo() @apiStrict
{
return 1;
}
Hmm I really like this.
If we could have an AttributeAliasSeq then we could solve all of
the inversion problems by simply removing them from the list.
This would also allow us to define a default set of attributes
(in say core.attribute) that every symbol (except templates?) get
tagged by.
Then you could change the default set of attributes by a version
switch.
Or we could have the default attribute set apply to the module
(declaration?) and be user overridable and then any explicit
attributes applied to symbols override the default module
attributes.
I think I'll write a DIP for this after my honours thesis.
