On Monday, 26 June 2017 at 16:51:06 UTC, Moritz Maxeiner wrote:
> As long as you don't introduce immutable by default, resulting in datastructures being littered with `mutable`.

Yeah, I'm against immutable by default. Also, my nogc, safe, etc by default idea does NOT apply to main() or virtual methods.

I have explained why before and feel like we are hijacking this thread now though....

On Monday, 26 June 2017 at 16:51:06 UTC, Moritz Maxeiner wrote:
> On Monday, 26 June 2017 at 16:10:01 UTC, H. S. Teoh wrote:
>>
>> Yes, please do!  If we can push this through, D could be in a much, much better place in a few years' time!
>
> As long as you don't introduce immutable by default, resulting in datastructures being littered with `mutable`.

Addendum: I'm also not in favor of `nothrow` by default, because imho that contradicts D's error handling using exceptions by default.

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;
}

On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
> Anyway, I think we could just have a compile time switch for defaults.

Imagine having n libraries with pairwise different required defaults used in your application. Say goodbye to combined compilation, hello n separate required compiler invocations.

> 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.

That's why most of what I do is in templates, so the compiler infers them for me, anyway.

>
> 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.

Except Rust is in exactly the same boat as D, because the same issues that apply to `@trusted` apply to `unsafe`, as well.

>
> 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;
> }

That would be useful.

On Monday, 26 June 2017 at 14:17:26 UTC, Adam D. Ruppe wrote:

> // next gen D
> module version(3.0) foo.bar; // opt in here
> void whatever() {} // now @safe by default

That's a really good idea.

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.

On Tuesday, 27 June 2017 at 02:19:56 UTC, Nicholas Wilson wrote:
> I think I'll write a DIP for this after my honours thesis.


Initial draft https://github.com/thewilsonator/DIPs/blob/Attributes/DIPs/DIPxxxx_attributes.md

Don't expect much from me until 4th of July.

On Monday, 26 June 2017 at 22:17:00 UTC, Moritz Maxeiner wrote:
> On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
>> Anyway, I think we could just have a compile time switch for defaults.
>
> Imagine having n libraries with pairwise different required defaults used in your application. Say goodbye to combined compilation, hello n separate required compiler invocations.
>

Yeah, that's true. I didn't really think of full source compilation of libs in your project. I though .lib would've been compiled with some settings and you'd just link with that and work with its api.

Also in reality I wouldn't want to be able to cancel @nogc in a function, because then the attribute would just lose power and you couldn't trust it. I just used it as a simple example for the @ and @! syntax that I'd like to have in general. Which would allow a nice way of working with sections of code like this:
class
{
@nogc:    or @!gc:
... some code ..
@gc:    or @gc:
... more code ..
@nogc:    or @!gc:
... even more code ..
}

>>
>> 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.
>
> Except Rust is in exactly the same boat as D, because the same issues that apply to `@trusted` apply to `unsafe`, as well.

Hmmm, I guess that's true. I don't really know a lot about Rust. Their safety story just sounds way more convincing and believable than D's. It would probably be the first language I'd look into if I was interested in low level safety critical code.

On Tuesday, 27 June 2017 at 19:06:19 UTC, Random D user wrote:
> On Monday, 26 June 2017 at 22:17:00 UTC, Moritz Maxeiner wrote:
>>
>> Except Rust is in exactly the same boat as D, because the same issues that apply to `@trusted` apply to `unsafe`, as well.
>
> Hmmm, I guess that's true. I don't really know a lot about Rust. Their safety story just sounds way more convincing and believable than D's. It would probably be the first language I'd look into if I was interested in low level safety critical code.

The power of having plenty of money to pay for (viral) marketing. Or in short: Propaganda.
Rust is a good PL, but in practice it isn't significantly safer than @safe D in my experience.
And you pay for that small difference dearly with productivity decrease (even after becoming comfortable with the borrow checker system).

On Tuesday, 27 June 2017 at 03:14:58 UTC, Nicholas Wilson wrote:
> On Tuesday, 27 June 2017 at 02:19:56 UTC, Nicholas Wilson wrote:
>> I think I'll write a DIP for this after my honours thesis.
>
>
> Initial draft https://github.com/thewilsonator/DIPs/blob/Attributes/DIPs/DIPxxxx_attributes.md
>
> Don't expect much from me until 4th of July.

https://github.com/dlang/DIPs/pull/75