On Sunday, 17 January 2021 at 02:02:00 UTC, Max Haughton wrote:
> On Sunday, 17 January 2021 at 00:28:02 UTC, Paul wrote:
>> [...]
>
> They would have the potential to make compiling really hard if they were allowed freely. If you imagine a mutable enum at module scope, it could be modified all over the place and lead to completely non-deterninistic compilation.
>
> Some mechanisms to (say) add to a table at compile time might be useful (you can fake this using ELF sections), but mutability is a footgun

We're getting aliases that may be assigned multiple times before being read; so why not?

On Sunday, 17 January 2021 at 01:51:21 UTC, Paul Backus wrote:
> Why add a dedicated new language feature if you can get the same behavior "for free" using regular old functions together with CTFE? D is already a pretty complex language, after all.

Because the alternative seems more complex to me.
It could be a lot more consistent as well, the way the keyword 'static' is used at the moment seems very inconsistent to me, the same could be said for manifest constants I think.
(Referring to static if, static foreach, static assert instead of static attributes)

Having a single keyword for all, with added expressiveness, seems a lot clearner & simpler to me.

On Sunday, 17 January 2021 at 15:59:31 UTC, Paul wrote:

> - compile time only variables (or functions*), as manifest constants cant be modified and normal variables are not useable inside mixins:
>> compile string waardes = "waarde.x";
>> static if(L>=2) waardes ~= ",waarde.y";
>> static if(L>=3) waardes ~= ",waarde.z";
>> static if(L==4) waardes ~= ",waarde.w";

&

> On Sunday, 17 January 2021 at 01:51:21 UTC, Paul Backus wrote:
>> Why add a dedicated new language feature if you can get the same behavior "for free" using regular old functions together with CTFE? D is already a pretty complex language, after all.
>
> Because the alternative seems more complex to me.
> It could be a lot more consistent as well, the way the keyword 'static' is used at the moment seems very inconsistent to me, the same could be said for manifest constants I think.
> (Referring to static if, static foreach, static assert instead of static attributes)
>
> Having a single keyword for all, with added expressiveness, seems a lot clearner & simpler to me.

If I wanted to make this into a serious language suggestion, how should I?
Does this require a DIP, or does it make sense to first start a discussion post solely about this topic? Am I even being realistic here, I have no idea ":\

On Wednesday, 20 January 2021 at 14:43:15 UTC, Paul wrote:
> If I wanted to make this into a serious language suggestion, how should I?
> Does this require a DIP, or does it make sense to first start a discussion post solely about this topic? Am I even being realistic here, I have no idea ":\

A DIP would be required before this feature could be officially added to the language, but generally it makes sense to discuss the idea with the community before writing a DIP. In this case, I believe it is very unlikely that such a DIP would be accepted because:

1. The problem it aims to solve can already be solved by existing language features (CTFE).
2. It adds a new keyword to the language.

On Wednesday, 20 January 2021 at 15:40:50 UTC, Paul Backus wrote:
> I believe it is very unlikely that such a DIP would be accepted because:
>
> 1. The problem it aims to solve can already be solved by existing language features (CTFE).
> 2. It adds a new keyword to the language.

It does seem to me that, were 'switch' to be a new feature, these points would hold as well, but I'll take your word for it 😅. However I do think having a new/seperate keyword for a concept that's already abusing the 'static' keyword would make more sense.
(Especially for people that have not used C)

On Wednesday, 20 January 2021 at 15:40:50 UTC, Paul Backus wrote:
> On Wednesday, 20 January 2021 at 14:43:15 UTC, Paul wrote:
>> If I wanted to make this into a serious language suggestion, how should I?
>> Does this require a DIP, or does it make sense to first start a discussion post solely about this topic? Am I even being realistic here, I have no idea ":\
>
> A DIP would be required before this feature could be officially added to the language, but generally it makes sense to discuss the idea with the community before writing a DIP. In this case, I believe it is very unlikely that such a DIP would be accepted because:
>
> 1. The problem it aims to solve can already be solved by existing language features (CTFE).
> 2. It adds a new keyword to the language.

I often found myself limited to leverage recursion unnecessarily only because I want to reshadow an enum or static variable.
Why isn't that possible, it hasn't to be mutation at all, only rebinding.