Remove link to SDK issue #33383 as linked target adds little to understanding

[osa1]

Page URL

https://dart.dev/language/libraries

Page source

No response

Describe the problem

The language guide links to dart-lang/sdk#33383 in a note in section "Libraries and visibility".

As a user I found that link more confusing than helpful. There's an answer in the thread, but I have to skip multiple comments to find it. Even after finding the answer, there are more comments from the language designers, so I'm like "maybe they're considering it now? let's read on".. except there's nothing other than more users requesting the feature. There are also people running polls etc.

It would be more respectful to the users (by not wasting their time) if we could just tell the reason, instead of making them dig and uncover it.

I tried to write a draft answer myself, but I don't know the language enough to answer it in detail, so help from language designers will be needed here.

Expected fix

Do not link to the issue tracker. Explain the reason why Dart uses _ prefix in identifiers instead of access modifiers in the same page.

Additional context

No response

[parlough]

Thanks for the suggestion, I agree that linking to a large issue with a lot of discussion isn't really helpful. I can put some thought in to how we could structure a more straight-forward, condensed explanation inline in the doc.

I do wonder if the explanation of "why" is even needed at all as part of the language tour though. Do you(or others passing by) find it helpful/relevant to learning Dart? It seems to be a remnant from when one of the main audiences of Dart was developers switching from Java. We don't explain a bunch of other design decisions behind Dart in the language tour.

[osa1]

I do wonder if the explanation of "why" is even needed at all as part of the language tour though. Do you(or others passing by) find it helpful/relevant to learning Dart?

Good point. I generally find it useful, as long is it doesn't make the text too verbose (e.g. maybe it's in a footnote, a separate page, or in an expandable section), for two reasons:

1. I'm a language implementer and designer myself, so I'm interested to know if a decision was made purely for social reasons (e.g. designers think feature X is bad for software engineering, it leads to unmaintainable software etc.), or it becomes necessary or impossible because of another feature in the language (e.g. as far as I understand Dart's dynamic makes it necessary for package-private and public method calls to be syntactically different).

2. Sometimes the "why" can hint at whether I should be hopeful for a fix or improvement. For example, Go didn't have generics for a long time, but when you read about it you would see that it's actually possible to implement generics without designing an entirely new language, it's just not something that the devs thought is needed, or maybe they didn't have the time yet etc.

So I personally would prefer seeing some explanation of the design decisions, but I think it also makes sense that in a document written for end users those should not be necessary.