> Fasten your seatbelt, it's gonna be a bumpy ride! :o)
>
> Andrei

The fundamentalness of the changes seem to be sufficient that one could argue it's D3. If you're going to make major changes wouldn't it be worth a fuller break to address some of the other unresolved and seemingly pretty major issues such as const/immutable and ref?

ixid:

> The fundamentalness of the changes seem to be sufficient that one could argue it's D3.

This seems a good idea.


> If you're going to make major changes wouldn't it be worth a fuller break to address some of the other unresolved and seemingly pretty major issues such as const/immutable and ref?

This seems a bad idea, because GC and scope tracking is a sufficiently large design & implementation space. You can't face all the large problems at the same time.

Bye,
bearophile

On 9/21/2014 3:12 PM, Andrei Alexandrescu via Digitalmars-d wrote:
> On 9/21/14, 12:35 PM, "Nordlöw" wrote:
>> On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote:
>>> Please chime in with thoughts.
>>
>> Why don't we all focus our efforts on upgrading the current GC to a
>> state-of-the GC making use of D's strongly typed memory model before
>> discussing these things?
>
> Not sure I understand, but: an important niche is apps that COMPLETELY
> disallow garbage collection -- Andrei

It's also far from being a zero sum game.  Work on one is not necessarily taking away from the other.  There needs to be more 'doing' that follows the discussions than there typically is.  But progress can and needs to be made on both (and many many other) fronts.

On 21/09/2014 03:35, deadalnix wrote:
>   - It is slow to compile.

Surely that's not an inherent property of Rust?

>   - Constraints too much the dev in some paradigms, which obviously
> won't fit all area of programming.

Absolutely. The unique mutable borrow rule too often prevents even reading a variable, this is a big pain IMO. I wonder if this is partly because Rust doesn't have const, only immutable.

>   - The macro system is plain horrible,

The syntax is not great (I heard it may change), but I think the capabilities are actually pretty good.

> and the only way to do code generation.

I think you're wrong, you can add syntax extensions such as the compile-time regex support:

http://blog.burntsushi.net/rust-regex-syntax-extensions

"Luckily, the second way to write a macro is via a syntax extension (also known as a “procedural macro”). This is done by a compile time hook that lets you execute arbitrary Rust code, rewrite the abstract syntax to whatever you want and opens up access to the Rust compiler’s parser. In short, you get a lot of power. And it’s enough to implement native regexes. The obvious drawback is that they are more difficult to implement."

Nick Treleaven:

>>  - It is slow to compile.
>
> Surely that's not an inherent property of Rust?

We don't know yet. Perhaps Rust type inference needs lot of computations.

Bye,
bearophile

On 9/22/14, 1:56 AM, ixid wrote:
>> Fasten your seatbelt, it's gonna be a bumpy ride! :o)
>>
>> Andrei
>
> The fundamentalness of the changes seem to be sufficient that one could
> argue it's D3.

Let's aim for not.

> If you're going to make major changes wouldn't it be
> worth a fuller break to address some of the other unresolved and
> seemingly pretty major issues such as const/immutable and ref?

What are the major issues with const/immutable and ref?


Andrei

On Monday, 22 September 2014 at 09:13:49 UTC, bearophile wrote:
> ixid:
>
>> The fundamentalness of the changes seem to be sufficient that one could argue it's D3.
>
> This seems a good idea.
>

No, it's not a good idea. Tweaking memory management shouldn't require the language branching. IMHO, this would be a suicide.

Piotrek

Piotrek:

> No, it's not a good idea. Tweaking memory management shouldn't require the language branching. IMHO, this would be a suicide.

I didn't meant the advancement as a language branching, but as a successive version that is (mostly) backwards compatible. Likewise C#6.0 is not a branching of C#5.

Bye,
bearophile

> What are the major issues with const/immutable and ref?

Const and immutable seem to be difficult to work with, Maxime wrote a piece about how difficult to use they were in practice. Ref is difficult to combine properly with generic templates, Manu covers that in another thread here.

Maxime's blog:
http://pointersgonewild.wordpress.com/2014/07/11/the-constness-problem/

Manu's post about the combinatorial complexity of ref for templates (which you've responded to earlier in the chain):
http://forum.dlang.org/post/mailman.1381.1411381413.5783.digitalmars-d@puremagic.com

On 21.9.2014. 22:57, Peter Alexander wrote:
> On Sunday, 21 September 2014 at 19:36:01 UTC, Nordlöw wrote:
>> On Friday, 19 September 2014 at 15:32:38 UTC, Andrei Alexandrescu wrote:
>>> Please chime in with thoughts.
>>
>> Why don't we all focus our efforts on upgrading the current GC to a
>> state-of-the GC making use of D's strongly typed memory model before
>> discussing these things?
>
> GC improvements are critical, but...
>
> "As discussed, having exception objects being GC-allocated is clearly a
> large liability that we need to address. They prevent otherwise careful
> functions from being @nogc so they affect even apps that otherwise would
> be okay with a little litter here and there."
>
> No improvements to the GC can fix this. @nogc needs to be usable,
> whether you are a GC fan or not.

I think that what is being suggested is that upgrading GC would widespread the point of view on what can and should be done.

For example, now that ranges and mixins exist great ideas comes to mind, and without them we can only guess. I think that GC is in the same position.