December 13
On Thursday, 13 December 2018 at 10:29:10 UTC, RazvanN wrote:
> Do you honestly think that they will ever take D into account if @safe and immutable data will be the default?

D needs to stop chasing after what you think people think they want and just start being good for us.

The majority of my code is written pretty permissively - I like my pointers, my gotos, my GC, my exceptions. But I'm willing to consider the change because I actually don't think it will be that big of a hassle, and will be better overall. I wanna show you something:

/// Static convenience functions for common color names
nothrow pure @nogc @safe
static Color transparent() { return Color(0, 0, 0, 0); }


The attribute spam is almost longer than the function itself. And I don't even personally care - I only put those in because some library user who did care filed a bug report, and that was before I would answer those with "WON'T FIX. D's attributes are a misdesigned waste of time. You shouldn't bother with them either"


If the defaults were swapped though, that would just work. Both for me and for my library users. And that is worth looking at.


Though, I think we could also get a lot of mileage out of fixing two glaring problems with the status quo: 1) making attr: at the top descend into aggregates consistently and 2) LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING.
December 13
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe wrote:
> I wanna show you something:
>
> /// Static convenience functions for common color names
> nothrow pure @nogc @safe
> static Color transparent() { return Color(0, 0, 0, 0); }

Enums could resolve this particular case.

My thought on this situation is to implement tuple expansion in attributes just like in function parameters, and complete DIP1012. Then we can write so:

---
alias noble = AliasSeq!(pure, nothrow, nogc, safe);

int queryStuff() const @noble
{
    ...
}
---

December 13
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
> I think there’s a general consensus that @safe, pure and immutable should be default.

I recall there was a decent chunk of people around D2.007 who were pushing for const-by-default function parameters on the grounds of if we're going to have this controversial system, we may as well commit to it.

Also in the topic of defaults, you could potentially add inout as a default for member functions. It's a lot more strict, but no more so than immutable by default.
December 13
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe wrote:
> Though, I think we could also get a lot of mileage out of fixing two glaring problems with the status quo: 1) making attr: at the top descend into aggregates consistently and 2) LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING.

While I might quibble about nothrow being the default, I wouldn't care once attributes descend into aggregates.

https://issues.dlang.org/show_bug.cgi?id=7616
December 13
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe wrote:

> 2) LETTING US TURN THEM OFF. SERIOUSLY WHY DON'T WE HAVE `virtual`, `throws`, `impure` AND THE REST?! THIS IS SO OBVIOUS AND THE LACK OF THEM IS UNBELIEVABLY FRUSTRATING.

Well, we had virtual, it was reverted....
I know, I'm repeating this kind of things in a trollish way since 2004, but... *sigh*

/Paolo


December 15
On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote:
> My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code.

I think it would be a bad idea for `immutable` because more often than not it would need to be turned off. I've heard Java called a "BSDM language" because it forces the programmer to type reams of unnecessary characters to accomplish ordinary tasks. This reminds me of that.
December 15
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote:
> A few things that have annoyed me about writing D lately:
>
> https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/

Wait, no word about ref parameters? No way!

If you try to bind to typical C++ code they are *EVERYWHERE*, add to that inability to make ref variable(well, it can be mimick'd by wrapping in a helper function but it still sucks) and it completely destroys the usability.

In its current form ref in D is PITA...

When it comes to C++ interop unfortunatelly it is too much left to wish
December 15
On Saturday, 15 December 2018 at 02:16:36 UTC, Nathan S. wrote:
> On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote:
>> My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code.
>
> I think it would be a bad idea for `immutable` because more often than not it would need to be turned off.

Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. @safe and pure though...


December 17
On Sat, 2018-12-15 at 19:53 +0000, Atila Neves via Digitalmars-d-announce wrote:
> On Saturday, 15 December 2018 at 02:16:36 UTC, Nathan S. wrote:
> > On Thursday, 13 December 2018 at 10:14:45 UTC, Atila Neves wrote:
> > > My impression is that it's a consensus that it _should_, but it's not going to happen due to breaking existing code.
> > 
> > I think it would be a bad idea for `immutable` because more often than not it would need to be turned off.
> 
> Not the case in Rust, not the case in how I write D. TBH it's not such a big deal because something has to be typed, I just default to const now anyway instead of auto. @safe and pure though...

Shouldn't be the case in Java either, since it is and always has been a single assignment supporting language – it's just that they made mutable the default, and trained people not use final.
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



December 17
On Saturday, 15 December 2018 at 19:53:06 UTC, Atila Neves wrote:

> @safe and pure though...

Why @safe? Can't you just write "@safe:" on top and switch to @system/@trusted as needed?
1 2 3 4 5 6 7 8 9