Menu
Search

Forums

Forum Index

June 18, 2023
Gravatar of Walter BrightPosted by Walter Bright
in reply to monkyyy		Reply
Walter Bright
Gravatar of Walter Bright
Posted in reply to monkyyy


Reply
On 6/17/2023 5:14 AM, monkyyy wrote:
> All you need to say is "d version 99 is the lts for the next 3 year" or maybe a formal blog post by 5ish people.

Somebody needs to step up and pull fixes into it.
June 19, 2023
Gravatar of FeepingCreaturePosted by FeepingCreature
in reply to Dany12L		Reply
FeepingCreature
Gravatar of FeepingCreature
Posted in reply to Dany12L


Reply

On Sunday, 18 June 2023 at 13:59:07 UTC, Dany12L wrote:

>

On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:

>

Frankly, anyone who wants to can step up and pick a version of D, declare it to be LTS, and pull only bug fixes to it, can do so.

After all this talk another unnecessary change that will break the code in the user has been accepted

https://github.com/dlang/dmd/pull/15319

Please Walter Bright check this...

I'm not sure about that one myself, even though I did it. (See my comment.) Right now, I'm mostly just hoping that nobody is calling private methods in that way. As I said, I could split it out into a separate deprecation but that would require undoing the error unification in the fix PR. And the whole this error happened like three separate times is because this check is split over a bunch of separate codepaths, so I'd hate to contribute to making it worse.

That said, the language working as specified and documented is not an "unnecessary change".

I think we're running the risk of falling into a hole of "code is fragile and unmaintainable, so don't change anything ever." Longstanding bugs going unfixed is a major contributor to code that is fragile and unmaintainable, because you cannot trust what it says! Not to mention this makes D a hellhole for new people to learn.

Years ago, I noted that learning D is not primarily a matter of learning the language. The language is intuitive and straightforward. Instead, learning D is primarily a matter of memorizing all the diverse places where the language is not intuitive and in fact is broken and you just have to avoid them. I think cutting down on that is more important than preserving the very specific ways in which you are sometimes permitted to call a private method if you have placed an unrelated public method in the right location in your code.

That said, honestly, look at the bug. They're calling a private method! That means they, or at least somebody, intended it to not be called! Even on its own merits, I really think this is a case where an error is just more valuable to the developer than no error.

June 19, 2023
Gravatar of Dany12LPosted by Dany12L
in reply to FeepingCreature		Reply
Dany12L
Gravatar of Dany12L
Posted in reply to FeepingCreature


Reply

On Monday, 19 June 2023 at 07:23:59 UTC, FeepingCreature wrote:

>

On Sunday, 18 June 2023 at 13:59:07 UTC, Dany12L wrote:

>

On Saturday, 17 June 2023 at 06:25:26 UTC, Walter Bright wrote:

>

Frankly, anyone who wants to can step up and pick a version of D, declare it to be LTS, and pull only bug fixes to it, can do so.

After all this talk another unnecessary change that will break the code in the user has been accepted

https://github.com/dlang/dmd/pull/15319

Please Walter Bright check this...

I'm not sure about that one myself, even though I did it. (See my comment.) Right now, I'm mostly just hoping that nobody is calling private methods in that way. As I said, I could split it out into a separate deprecation but that would require undoing the error unification in the fix PR. And the whole this error happened like three separate times is because this check is split over a bunch of separate codepaths, so I'd hate to contribute to making it worse.

That said, the language working as specified and documented is not an "unnecessary change".

I think we're running the risk of falling into a hole of "code is fragile and unmaintainable, so don't change anything ever." Longstanding bugs going unfixed is a major contributor to code that is fragile and unmaintainable, because you cannot trust what it says! Not to mention this makes D a hellhole for new people to learn.

Years ago, I noted that learning D is not primarily a matter of learning the language. The language is intuitive and straightforward. Instead, learning D is primarily a matter of memorizing all the diverse places where the language is not intuitive and in fact is broken and you just have to avoid them. I think cutting down on that is more important than preserving the very specific ways in which you are sometimes permitted to call a private method if you have placed an unrelated public method in the right location in your code.

That said, honestly, look at the bug. They're calling a private method! That means they, or at least somebody, intended it to not be called! Even on its own merits, I really think this is a case where an error is just more valuable to the developer than no error.

I think there is a misunderstanding here, saying that a particular language behavior is wrong according to the specification is different than throwing an error in the compiler.

Is issue 21275 incorrect according to the language specification? Yes
Is the behavior unpredictable? No, so there is no reason to throw an error

Simply issue a deprecation or warning message and allow the user to ignore it or treat it as an error, the fact that it is against the specification does not prevent the compiler from generating a working executable with predictable behavior.

There is no reason to throw errors for these things, C/C++ compilers don't do that and that allow the developer time to fix without preventing the code from compiling.

June 19, 2023
Gravatar of MartynPosted by Martyn
in reply to Walter Bright		Reply
Martyn
Gravatar of Martyn
Posted in reply to Walter Bright


Reply
On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:
> On 6/17/2023 5:14 AM, monkyyy wrote:
>> All you need to say is "d version 99 is the lts for the next 3 year" or maybe a formal blog post by 5ish people.
>
> Somebody needs to step up and pull fixes into it.

OK - while I am a developer that has used D for minor programs on my home systems (and someone who visits the forums and conf videos often) - I am happy to step up to support/contribute LTS. However, I am not in a position to do this right now. Not because "I am busy" or similar, I need to understand the internals and community process of the D language.

I guess I am a "user" of Dlang, but happy to dive into the dev world.

When I am ready (and noone else had stepped up to handling LTS) I will likely create a new post to kick things off officially.

Thanks.
June 19, 2023
Gravatar of bachmeierPosted by bachmeier
in reply to Walter Bright		Reply
bachmeier
Gravatar of bachmeier
Posted in reply to Walter Bright


Reply
On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:
> On 6/17/2023 5:14 AM, monkyyy wrote:
>> All you need to say is "d version 99 is the lts for the next 3 year" or maybe a formal blog post by 5ish people.
>
> Somebody needs to step up and pull fixes into it.

If you go back only three years, that means there are currently nine major releases of DMD still in use in the wild, plus whatever releases of LDC and GDC have happened since then. Are they getting bug fixes? If not, why not?

We all know that requiring LTS to get all bug fixes makes it a big project, and that the probability of someone actually doing it is zero. It's not necessary and it's not sufficient to solve the problem of having to support too many compiler releases.
June 19, 2023
Gravatar of RazvanNPosted by RazvanN
in reply to Martyn		Reply
RazvanN
Gravatar of RazvanN
Posted in reply to Martyn


Reply
On Monday, 19 June 2023 at 10:35:34 UTC, Martyn wrote:
> On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:
>> On 6/17/2023 5:14 AM, monkyyy wrote:
>>> All you need to say is "d version 99 is the lts for the next 3 year" or maybe a formal blog post by 5ish people.
>>
>> Somebody needs to step up and pull fixes into it.
>
> OK - while I am a developer that has used D for minor programs on my home systems (and someone who visits the forums and conf videos often) - I am happy to step up to support/contribute LTS. However, I am not in a position to do this right now. Not because "I am busy" or similar, I need to understand the internals and community process of the D language.
>
> I guess I am a "user" of Dlang, but happy to dive into the dev world.
>
> When I am ready (and noone else had stepped up to handling LTS) I will likely create a new post to kick things off officially.
>
> Thanks.

Hi Martyn,

If you need any help in any direction, feel free to contact myself or Dennis on whatever channel you want (Gmail, slack, discord etc.)

Best regards,
RazvanN
June 19, 2023
Gravatar of MartynPosted by Martyn
in reply to bachmeier		Reply
Martyn
Gravatar of Martyn
Posted in reply to bachmeier


Reply
On Monday, 19 June 2023 at 13:38:58 UTC, bachmeier wrote:
> On Sunday, 18 June 2023 at 17:49:38 UTC, Walter Bright wrote:
>> On 6/17/2023 5:14 AM, monkyyy wrote:
>>> All you need to say is "d version 99 is the lts for the next 3 year" or maybe a formal blog post by 5ish people.
>>
>> Somebody needs to step up and pull fixes into it.
>
> If you go back only three years, that means there are currently nine major releases of DMD still in use in the wild, plus whatever releases of LDC and GDC have happened since then. Are they getting bug fixes? If not, why not?
>
> We all know that requiring LTS to get all bug fixes makes it a big project, and that the probability of someone actually doing it is zero. It's not necessary and it's not sufficient to solve the problem of having to support too many compiler releases.

I agree. While I don't think LTS releases needs to "get all bug fixes" - it doesn't stop it being a big project.

While some people may think this is a case of simply creating an LTS branch and... boom.. job done. It wont be as simple as that.

This needs some careful planning before going ahead with this. Besides, it is not worth putting effort into LTS if D developers are not onboard, especially library creators/maintainers. It is a change, afterall. One I am not willing to jump straight in without a cohesive plan.

This is especially the case for bug fixes towards an LTS - as we have to consider not just DMD, but GDC and LDC.

This wont be a one-man-task. I would guess atleast 3 people - 1 per compiler.. minimum.

I don't think this will happen overnight. It will likely to be an oppotunity when it presents itself. How or when, I don't know. Maybe this wont come to fruition for a number of years.

  (wont stop me atleast looking into dmd compiler, atleast)

I want to see Dlang succeed. In my opinion, having LTS is a stepping stone towards this goal (even if it is a tiny stone in the grand scheme of things)
  - of course thats my opinion.
June 19, 2023
Gravatar of MartynPosted by Martyn
in reply to RazvanN		Reply
Martyn
Gravatar of Martyn
Posted in reply to RazvanN


Reply
On Monday, 19 June 2023 at 13:59:25 UTC, RazvanN wrote:
>
> Hi Martyn,
>
> If you need any help in any direction, feel free to contact myself or Dennis on whatever channel you want (Gmail, slack, discord etc.)
>
> Best regards,
> RazvanN

Thank you!
June 20, 2023
Gravatar of Richard (Rikki) Andrew CattermolePosted by Richard (Rikki) Andrew Cattermole
in reply to Martyn		Reply
Richard (Rikki) Andrew Cattermole
Gravatar of Richard (Rikki) Andrew Cattermole
Posted in reply to Martyn


Reply
You're overthinking it a bit.

We have had (and to some extent still do) have LTS in terms of dmd-fe codebase.

It was done by Iain by himself pretty much.

https://forum.dlang.org/post/u5tg5u$1mce$1@digitalmars.com

See Iain's replies as to what needs to happen to do this proper.
June 19, 2023
Gravatar of MartynPosted by Martyn
in reply to Richard (Rikki) Andrew Cattermole		Reply
Martyn
Gravatar of Martyn
Posted in reply to Richard (Rikki) Andrew Cattermole


Reply
On Monday, 19 June 2023 at 14:28:04 UTC, Richard (Rikki) Andrew Cattermole wrote:
> You're overthinking it a bit.
>
> We have had (and to some extent still do) have LTS in terms of dmd-fe codebase.
>
> It was done by Iain by himself pretty much.
>
> https://forum.dlang.org/post/u5tg5u$1mce$1@digitalmars.com
>
> See Iain's replies as to what needs to happen to do this proper.

Thanks - those replies might have skipped me. Will look for them.
« First   ‹ Prev
… 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Next ›   Last »