January 17

On Wednesday, 17 January 2024 at 15:30:27 UTC, zjh wrote:

>

Very similar to the plugin style development of vim!

Transform the 'dip' of 'd' into a 'vim 'like' plugin that users can freely assemble and update at any time.

January 17

On Wednesday, 17 January 2024 at 15:30:27 UTC, zjh wrote:

>

On Wednesday, 17 January 2024 at 15:17:47 UTC, zjh wrote:

>

I think it's more convenient to integrate it into the 'experimental switch', after all, there maybe too many experiments dip switch.

Countless dips, as long as contributors think there is a good idea, they can try it out, and then, if everyone thinks it's good, they can join.
If there are still issues, they can be continuously corrected during use, while also improving the details of the dip.
If there is a major problem and the 'dip' is not recommended, cancel it!
Very similar to the plugin style development of vim!
These switches are implemented by contributors, which can fully mobilize their enthusiasm!

Dip1027/Dip1036 can all be added, experiment for 1 year or half a year, and then see which is better! Instead of endless debates.

This is a good point. Rust has unstable features that are only available on their nightly builds. Some of them are also gated behind a feature flag. The end result is that the community has plenty of time to test out new features and hash out any dark corners.

January 17

On Wednesday, 17 January 2024 at 19:29:28 UTC, Meta wrote:

>

This is a good point. Rust has unstable features that are only available on their nightly builds. Some of them are also gated behind a feature flag. The end result is that the community has plenty of time to test out new features and hash out any dark corners.

Forgot the link:
https://doc.rust-lang.org/rustdoc/unstable-features.html
https://doc.rust-lang.org/unstable-book/index.html

January 17
On 1/17/2024 7:07 AM, zjh wrote:
> Yes, why don't I participate in these debates because I can't even `try them out`. How do I know the `pros and cons`?
> Only after `practical testing` can a more specific understanding be obtained. Otherwise, it is just `nonsense`.
> And the `endless debate` is a waste of time!

If you can build the compiler, it's not hard to merge a fork into your local copy and then build it.

I had trouble with that because every search query gave me the wrong git command to do this. I wound up asking some team members, and got the right command.

The forking system is the way to do this. It isn't very practical to try and maintain binaries of each PR.

DMD is pretty friendly to build from scratch. On my machine:

time make debug

takes 26 seconds to build on an ancient Linux box.
January 18
On 1/17/24 15:26, RazvanN wrote:
> On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote:
>> On Wednesday, 17 January 2024 at 02:16:01 UTC, zjh wrote:
>>> On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
>>>> https://github.com/dlang/dmd/pull/15715
>>>>
>>>> I was unconvincing in my arguments, there was too much acrimony, and its effects do not affect the rest of the language.
>>>
>>>
>>>
>>> In fact, two switches can also be provided for continuous feedback during use.
>>> We should also establish an `experimental mechanism` that allows for the revocation of the switch if it causes significant harm!
>>
>> I agree with that
>>
>> It should have been like other features, both under -preview switch, then a period of several months for testing, then a debate in forums about wich is better
>>
>> Do this with tuple, pattern matching, and tagged union, so people can test, give feedback, propose improvements without commitment for integration
>>
>>
>> I already use 2 preview switches in my project:
>>
>> -preview=rvaluerefparam
>> -preview=bitfields
>>
>>
>> I love rvaluerefparam, it should go core, but bitfields is imo bad, i'd prefer to be able to get bit specific integer type instead..
>>
> 
> Please be careful with that switch as it has a lot of bugs (and as far as I remember it's not completely implemented). I have tried turning it on by default in the compiler and was not able to compile phobos (however, I do not remember what the problems were).
> 
> RazvanN
> 
> 

Well, Phobos relies on rvalues not binding to ref parameters in order to check via `__traits(compiles, ...)` whether something is an lvalue.


January 18

On Wednesday, 17 January 2024 at 15:07:08 UTC, zjh wrote:

>

On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote:

>

I already use 2 preview switches in my project:

-preview=rvaluerefparam
-preview=bitfields

I love rvaluerefparam, it should go core, but bitfields is imo bad, i'd prefer to be able to get bit specific integer type instead..

I personally have no need for string interpolation

Yes, why don't I participate in these debates because I can't even try them out. How do I know the pros and cons?
Only after practical testing can a more specific understanding be obtained. Otherwise, it is just nonsense.
And the endless debate is a waste of time!

Majority isn't always right. This might not end up well. Debate is good. Just have to be healthy.

January 18

On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright wrote:

>

DMD is pretty friendly to build from scratch. On my machine:

time make debug

takes 26 seconds to build on an ancient Linux box.

It doesn't work like this. The process of building DMD starts from going to https://github.com/dlang/dmd and then reading (or at least skimming through) a number of web pages and clicking through them to navigate to the right place with the appropriate build instructions:

This kinda violates the https://en.wikipedia.org/wiki/Three-click_rule, which isn't a gospel, but still has some merit. All of this together is surely doable, but takes way longer than 26 seconds and the CPU speed isn't the bottleneck.

And I'm even not talking about building D compilers on unpopular marginal operating systems, such as Windows, which barely have any support at all:

January 18

On Thursday, 18 January 2024 at 09:29:03 UTC, Siarhei Siamashka wrote:

>

On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright wrote:

>

DMD is pretty friendly to build from scratch. On my machine:

time make debug

takes 26 seconds to build on an ancient Linux box.

It doesn't work like this. The process of building DMD starts from going to https://github.com/dlang/dmd and then reading (or at least skimming through) a number of web pages and clicking through them to navigate to the right place with the appropriate build instructions:

This kinda violates the https://en.wikipedia.org/wiki/Three-click_rule, which isn't a gospel, but still has some merit. All of this together is surely doable, but takes way longer than 26 seconds and the CPU speed isn't the bottleneck.

And I'm even not talking about building D compilers on unpopular marginal operating systems, such as Windows, which barely have any support at all:

Funny thing is, DMD is super easy to build on Windows. You just have to somehow figure out to rdmd build.d in the compiler directory and then it's all good. Phobos/Druntime on the other hand simply cannot be built on windows, because instructions tell you to use make that "comes with dmd`, and it just doesn't :)

January 18

On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright wrote:

>

The forking system is the way to do this. It isn't very practical to try and maintain binaries of each PR.

It's not necessary to maintain binaries of each PR. We are talking about potentially having pre-built compiler binaries for DIP1036e or for any other proposed controversial language features, which instigate a lot of debates. The point was made about the existence of a certain fraction of users, who have no skills or patience to build the patched compiler themselves. These people feel left out. Well, in a way that's their fault and nobody has any obligation to help them.

January 18
On Wednesday, 17 January 2024 at 10:58:44 UTC, Dibyendu Majumdar wrote:
> On Wednesday, 17 January 2024 at 10:54:07 UTC, claptrap wrote:
>> You are niave and misinformed, alot of people, even core devs are not happy with how things are managed.
>>
>> And I'm not attacking anyone, it's just debate and criticism.
>>
>
> Its people like you who are the problem.
>
> In all the discussions, Walter always argues technical points, he never abuses or name calls people or attacks them personally.
>
> It is the contributors job to convince not the other way round.

see, there's your problem. it's not the contributors job, they do this in their free time.
if you want contributions you simply cannot act like that.