April 08, 2020
On Saturday, 28 March 2020 at 20:08:18 UTC, krzaq wrote:
>> In this case wouldn't it be better to rename them to shorter u8, i8 .. u64, i64 and f32 .. f64. This is actually not a breaking change and we can implement it today if we want to with the old type names still there. Also, you can make whatever alias you want.
>
> I would love that. This is one of the things that Rust got 100% right.
>
> I know you can make whatever alias you want, but the point is that it's not universally used.  Standarization is important, that's why I'd use the fugly C names in C/C++ even though I could alias them away.

+1 i like the short names
April 08, 2020
On Monday, 30 March 2020 at 08:07:38 UTC, Andrea Fontana wrote:
> Some things I'd like to see in d3 that can't be done without breaking D:
> - Fixing attribute syntax: @safe vs pure (why not @pure?) or @safe vs @nogc (why no-prefix?). It would be nice to have #pure #safe #gc and their negative. And leave @ for UDA. So we have no need to reserve any keyword.
> - Remove unfinished things. For ex.: multiple alias this, @property, real, cfloat, ucent, etc...
> - Fixing range, autodecoder, ...
> - Removing old modules from phobos
> - Adding some features like string interpolation, static initialization of AAs
>
> Andrea

+1 good suggestions
April 09, 2020
On Wednesday, 8 April 2020 at 16:44:57 UTC, Istvan Dobos wrote:

>> Some issues I can think of:
>>
>> 1. The safe by default debate
>> 2. pure by default
>> 3. nothrow by default
>> 4. String interpolation DIP
>> 5. auto-decoding
>> 6. range.save
>> 7. virtual by default
>> 8. ProtoObject

Fix the internals in D that prevent changing the GC to be faster.
April 09, 2020
On 09.04.20 01:24, Kaitlyn Emmons wrote:
> On Saturday, 28 March 2020 at 17:09:34 UTC, Denis Feklushkin wrote:
> 
>>
>> int -> int32
>> ulong -> uint64
>> float -> float32
>> double -> float64
>> byte -> octet
> 
> if ulong is uint64.. byte should be uint8

byte is actually signed. There's ubyte. :)
April 09, 2020
On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.
>
> Having a new branch of the compiler will provide a way to keep D2 development alive while giving a playground to add new mechanisms, fix long-existing design issues, and provide an opt-in for code breakage.
>
> Some issues I can think of:
>
> 1. The safe by default debate
> 2. pure by default
> 3. nothrow by default
> 4. String interpolation DIP
> 5. auto-decoding
> 6. range.save
> 7. virtual by default
> 8. ProtoObject
>
> Other languages evolve much quicker than D, but break things only in major updates. D seems to "sort of" break things, there's always a risk in every release. We try to be conservative, but we have this horrible mix of deciding some features can break things, while others are not allowed to, and there's no clear guide as to which breakage fits in which category.
>
> If we went to a more regular major release schedule, and decided for a roadmap for each major release what features would be included, it would allow much better planning, and much more defensible breakage of code. If you know that your code will only compile with D2.x, and you're fine with that, then great, don't upgrade to D3.x. If you desperately want a feature, you may have to upgrade to D3.x, but once you get there, you know your code is going to build for a while.
>
> We could also not plan for many major releases, but at least move to D3 for some major TLC to the language that is held back to prevent breakage.
>
> I work occasionally with Swift, and they move very fast, and break a lot of stuff, but only in major versions. It's a bit fast for my taste, but it seems to work for them. And they get to fix issues that languages like C++ might have been stuck with forever.
>
> The biggest drawback is that we aren't a huge language, with lots of manpower to keep x branches going at once.
>
> I just wanted to throw it out as a discussion point. We spend an awful lot of newsgroup server bytes debating things that to me seem obvious, but have legitimate downsides for not breaking them in a "stable" language.
>
> -Steve

Thank you Steve!

I want to upgrade to dlang 3.0 and need change it:
1. ARC for GC is default
2. So fast json library
3. Async and await for D
4. Organize standard library

-Brian

April 09, 2020
On Thursday, 9 April 2020 at 13:48:15 UTC, zoujiaqing wrote:
> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>> [...]
>
> Thank you Steve!
>
> I want to upgrade to dlang 3.0 and need change it:
> 1. ARC for GC is default
> 2. So fast json library
> 3. Async and await for D
> 4. Organize standard library
>
> -Brian

Beware of ARC by default, usually the reality isn't the same as vocal anti-tracing GC wishes for.

https://github.com/ixy-languages/ixy-languages

https://www.modernescpp.com/index.php/memory-and-performance-overhead-of-smart-pointer

"CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default."
https://www.youtube.com/watch?v=JfmTagWcqoE

--
Paulo Pinto

April 10, 2020
On Thursday, 9 April 2020 at 13:48:15 UTC, zoujiaqing wrote:

> Thank you Steve!
>
> I want to upgrade to dlang 3.0 and need change it:
> 1. ARC for GC is default
> 2. So fast json library
> 3. Async and await for D
> 4. Organize standard library
>
> -Brian

It's my wishlist too!
April 11, 2020
So in D3 can we scrap the CTFE engine all together and just write a real D interpreter!

I suggest this actually be written FIRST before a compiler.. and then make compilation a feature of the interpreter! Flip the paradigm and unleash the true capabilities of meta programming!!
April 11, 2020
On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.

I'd say 2.080 was the first D3 release, where the move towards default safety seriously started, now it's only a debate of how much intended breakage should happen.
April 13, 2020
Oh and in D3 can we clean up "is"? Its like the syntax version of mom spaghetti.
D2 has fallen into the same trap c++ has.. never cleaning up old bad features!



PLEASE BREAK MY CODE!! A BETTER LANGUAGE IS WORTH CODE BREAKAGE..



how is that not obvious.. if we cared about not having to rewrite code we would all still be using cpp.. just BREAK D2 already!! DAMN.. its old and getting stale..

I just wanted to say that cus this thread will most likely die out like the n other threads about this topic.. nothing ever gets done.. even though there has been strong desire for D3 in the community for like 6 years now or something.. WALTER THIS IS ON YOU! MAKE THE DECISION TO KILL D2 PLEASE WE BEG YOU <3