I approved DIP1036e (page 3)

Settings

Help

Index » General » I approved DIP1036e (page 3)

January 17

Re: I approved DIP1036e

Posted by ryuukk_
in reply to zjh

Permalink

ryuukk_

Posted in reply to zjh

Permalink

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..

I personally have no need for string interpolation

January 17

Re: I approved DIP1036e

Posted by RazvanN
in reply to ryuukk_

Permalink

RazvanN

Posted in reply to ryuukk_

Permalink

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.

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

January 17

Re: I approved DIP1036e

Posted by bachmeier
in reply to M.M.

Permalink

bachmeier

Posted in reply to M.M.

Permalink

On Wednesday, 17 January 2024 at 14:06:28 UTC, M.M. wrote:

> I myself saw his comparison of DIP1027 to DIP1036, YAIDIP, and DIP1036e as demonstrating his overall general wish for "simple solutions" with "little corner and special cases"; in this view, bringing back DIP1027 demonstrates this part very concretely (instead of abstractly). But I certainly see that using your lenses the overall approach of Walter can be seen as pushing for own solution (and not arguing for a general simpler solution).

That was my interpretation too. I didn't read all of the posts, but my impression is that Walter didn't fully understand what people wanted to do with SQL, and it's not reasonable to expect anyone to understand every use for a programming language. It's frustrating, but communication is difficult when it involves other humans.

January 17

Re: I approved DIP1036e

Posted by ryuukk_
in reply to RazvanN

Permalink

ryuukk_

Posted in reply to RazvanN

Permalink

On Wednesday, 17 January 2024 at 14:26:29 UTC, 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.

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..

RazvanN

It's been working just fine for me, for years already, i don't do RAII or complex stuff with constructors tho, so that's maybe why

Are the issues referenced somewhere?

January 17

Re: I approved DIP1036e

Posted by claptrap
in reply to M.M.

Permalink

claptrap

Posted in reply to M.M.

Permalink

On Wednesday, 17 January 2024 at 14:06:28 UTC, M.M. wrote:
> On Wednesday, 17 January 2024 at 12:41:17 UTC, claptrap wrote:
>> On Wednesday, 17 January 2024 at 12:28:31 UTC, M.M. wrote:
>>> On Wednesday, 17 January 2024 at 11:40:31 UTC, claptrap wrote:
>>>>
>>>
> I personally thought that the discussion could have been swifter (but then again, we would perhaps end up with DIP1036 instead of DIP1036e)

I agree with most of what you've said.

However when someone says, "yes it was acrimonious but at least it led to a better DIP" they're brushing over fact that it could have been handled differently at still got the same result.

If youre telling youself the ends justify the means then you better think harder about what your doing.

January 17

Re: I approved DIP1036e

Posted by zjh
in reply to ryuukk_

Permalink

zjh

Posted in reply to ryuukk_

Permalink

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!

January 17

Re: I approved DIP1036e

Posted by zjh
in reply to RazvanN

Permalink

zjh

Posted in reply to RazvanN

Permalink

On Wednesday, 17 January 2024 at 14:26:29 UTC, RazvanN wrote:

RazvanN

These details should be noted in the document.
The more information in the document, the more users can obtain the most real situation.

January 17

Re: I approved DIP1036e

Posted by Siarhei Siamashka
in reply to zjh

Permalink

Siarhei Siamashka

Posted in reply to zjh

Permalink

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

I can't even try them out.

Why is this so? Do you find it difficult to build a patched DMD yourself? Would it help to have pre-built binary compiler releases for every DIP available for download somewhere?

January 17

Re: I approved DIP1036e

Posted by zjh
in reply to Siarhei Siamashka

Permalink

zjh

Posted in reply to Siarhei Siamashka

Permalink

On Wednesday, 17 January 2024 at 15:12:58 UTC, Siarhei Siamashka wrote:

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

I can't even try them out.

Why is this so? Do you find it difficult to build a patched DMD yourself?

I am a beginner user, I just want to use it unboxing. I am too lazy.

Would it help to have pre-built binary compiler releases for every DIP available for download somewhere?

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

January 17

Re: I approved DIP1036e

Posted by zjh
in reply to zjh

Permalink

zjh

Posted in reply to zjh

Permalink

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.

Top | Forum index | About this forum

Forums