Comments (6)
I added the rule that super._
is an error because the desugaring will turn it into code that doesn't work (or code that does something completely different! - if _
in super(..., _, ...)
will now denote a static or top-level declaration).
We could try to enable super._
by introducing an implicit renaming step that makes it possible for the superinitializer to denote this parameter. However, I think that would be an anomaly, and it is yet another exception to remember while coding.
So I'd prefer that we keep super._
as an error. Developers may then do the rename themselves. First case, it's in the same library:
// Current code. Breaks because `super._` will be an error.
class A {
final int _;
A(this._);
}
class B extends A {
B(super._);
}
// Migrated code. No problem, no rename lints, no code outside this library can know.
class A {
final int __;
A(this.__);
}
class B extends A {
B(super.__);
}
Other approaches can be used as well, of course. For example, the initializing formal in A
could be turned into a normal parameter with some other name (say, __
), such that the name of the instance variable wouldn't have to change, and we'd have A(int __) : _ = __;
.
In the other case, where A
and B
are declared in two distinct libraries, we might introduce a lint message which would then need to be ignored:
class OtherB extends A {
OtherB(super._);
}
class OtherB extends A {
// ignore: matching_super_parameters
OtherB(super.__);
}
In general, we will continue to allow developers to use _
as the name of some declarations. But I do not think we should bend over backwards to make it convenient to do so, at the expense of the consistency and comprehensibility of these parts of the language.
from sdk.
Another thought: Maybe we should treat all of __
, ___
etc. as non-binding declarations too. It's not necessary, but I'm not sure I'd want someone to write __
as a name, just to not have it be non-binding, and still not give the thing a real name.
It's a little iffy, because then they should probably work the same in patterns too. And that's an unrelated breaking change.
(Still think it would be prettier.)
from sdk.
Moved all discussions to their own issues. Easier to keep track :)
from sdk.
I just checked, and the icky thing I disagree with is disallowing super._
.
We should allow it.
If it breaks the current desugaring specification of super
parameters, then define super._
as introducing a fresh name instead of no name.
from sdk.
I think we should allow super._
because I don't expect users to expect an exception, so it not working is a surprising exception to them.
If the author doesn't use the name of a positional super.x
parameter, it's reasonable to assume that changing it to super._
is fine. After all, they can change it to super.y
or super._arglebargle
without any problem.
The reasoning that the specification uses the name is meaningless to the user. Can't it just not do that? Yes, yes it can. It's an accident of specification that the name is used, not anything inherent to the feature. It used to be a safe assumption that the name given to the parameter would still be in scope and refer to the same value at the point of the super constructor invocation, so the specification chose to specify the meaning as a desugaring to an invocation that references the parameter variable. That's no longer safe if we allow super._
, but that shouldn't break the wildcard feature by disallowing a meaningful use, it just means that the specification of super parameters shouldn't make that assumption any more, and should be rewritten to work anyway.
We can make it work. How we do that is up to us, it shouldn't matter to the user that we wrote a specification for super parameters that wasn't forward compatible. That's our problem, and we should solve it, and allow super._
.
from sdk.
Another thought: Maybe we should treat all of
__
,___
etc. as non-binding declarations too. It's not necessary, but I'm not sure I'd want someone to write__
as a name, just to not have it be non-binding, and still not give the thing a real name.
I considered that when I was first writing the proposal. You're point about it being inconsistent with patterns is, I think, a good one.
Also, we ultimately want to get to a world where people don't use __
, ___
, etc. So I think scoping wildcards to only be a single _
helps us go in that direction.
from sdk.
Related Issues (20)
- [wildcards] Quick fix: convert `UNUSED_LOCAL_VARIABLE` to wildcard
- [vm/ffi] Add `dladdr` embedder callback
- Analyzer Feedback from IntelliJ
- bug: FutureOr<FutureOr<Object>> does not resolve to FutureOr<Object> HOT 1
- Analyzer allows `super` as expression in several places HOT 1
- future doesn't throw correctly inside try block HOT 1
- [vm/ffi] Support `.address.cast()` in leaf calls
- File APIs inconsistently handle paths ending in `.` on windows in 3.4.3 HOT 2
- [infra] `tools/patches/flutter-engine/apply.sh` incompatible with Python 3.12
- New coverage_closure_call_after_optimization_test is timing out on AOT
- Compiler crash HOT 1
- Document machine/rules.json HOT 1
- Issues with Socket and SecureSocket error handling and documentation
- [CP] [dart2wasm] Make `dart compile wasm` compiled apps disable `dart.library.ffi` HOT 4
- Quick fix: convert `UNUSED_CATCH_CLAUSE` to wildcard
- [CP] Pub: Properly handle case where the client is unable to fetch advisories HOT 3
- Analyzer Feedback from IntelliJ
- [cfe/macros]: empty metadata iterable at compile time
- dart.exe take %97 of memory make pc laggy HOT 3
- New error message for `depend_on_referenced_packages` quick-fix HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sdk.