Missing function parameter type detection. #4230
Comments
|
I hope that in both cases ide correctly alerts to the type error. |
|
Could you please edit your post and add the code as properly formatted text. |
|
This behavior is due to a combination of type inference and variance rules in Dart. I will do my best to explain both of these concepts. I am almost certain that @eernstg is one of the best people to correct me, so I’m tagging him to review this 😉. InferenceWhen you call
VarianceDart collections like List<String> arr = ['a', 'b', 'c'];
test<Object>(arr, 123); // This inserts an `int` into a `List<String>`, violating type safety.At runtime, the program crashes when trying to insert an Why there’s no compile-time error without assignment?In the call In contrast, when you write: a = test(arr, 123);You explicitly constrain
These constraints are contradictory, so Dart reports a compile-time error. Simplified ExampleIf we simplify your program to remove inference: void main() {
Object test(List<Object> arr, Object value) {
arr[0] = value; // Runtime error: cannot insert `int` into `List<String>`.
return value;
}
List<String> arr = ['a', 'b', 'c'];
test(arr, 'd'); // No error: `arr` can hold a `String`.
test(arr, 123); // Runtime error: tries to insert `int` into a `List<String>`.
}This demonstrates the problem: Dart allows the covariant assignment of What can you do?While this behavior is "working as expected" according to Dart’s current type system, it can be surprising and problematic for developers. This stems from Dart’s unsound variance (#213). If Dart had sound variance, such issues would be caught at compile-time. So please upvote the following issues to make the Dart Team prioritize this problem: #213, #524, #753 |
|
I think it infers "dynamic", not "Object". Not sure. |
|
Dart 3.6.1 seems to infer as As @tatumizer mentioned, you can also explicitly give Today I learned, Dart infers scoped functions |
|
(Off-topic: Do you know what setting controls the appearance of |
|
That's a great explanation, @rubenferreira97! @tatumizer wrote:
This is actually a murky corner of Dart type inference as currently it is implemented. The specification in inference.md says that the greatest closure of a type variable is This means that we'd get Right now we just have to live with the fact that some occurrences of Also, of course, instantiation to bound is specified to use You can use analyzer settings like In the given example the inferred type argument is @rubenferreira97 wrote:
This is true, but not very practical. We wouldn't want to remember every single case where we need to provide the actual type arguments explicitly in a function call, because it is unsafe otherwise. Also, it's still unsafe with some actual type arguments that aren't void foo<X>(List<X> xs, X x) => xs.add(x);
void main() {
// Let's say we got `xs` from somewhere, and we have forgotten that it's a `List<int>`.
List<num> xs = <int>[1, 2, 3];
foo(xs, 1.5); // No compile-time error. Throws.
foo<num>(xs, 1.5); // No compile-time error. Throws.
}Issue #524 is a proposal to add support for statically checked variance to Dart. If this feature had been available in Dart today, and if class List<inout E> implements Iterable<E> { // OK, the real thing has more stuff.
...
}.. then There's a price to pay for this, though, which is that a lot of usages which are actually safe in current Dart are now compile-time errors. Roughly, any usage of a list that only reads elements and doesn't insert new ones is safe, even when the typing is covariant (that is, for example, a list with static type It's getting late, so I'll go home now. But I'll write more about how to avoid this kind of type error tomorrow. ;-) |
(Sorry for going off-topic. Maybe GitHub will implement DMs someday.) @tatumizer These are called Inlay Hints. If you’re using VSCode, you can press Ctrl+Alt (Windows) or Ctrl+Option (macOS) to toggle them while holding the keys. To enable or disable them permanently, you can configure your VSCode Workspace/User settings using the following options ( {
"[dart]": {
"editor.inlayHints.enabled": "offUnlessPressed"
}
}Note: There’s an annoying bug (Dart-Code/Dart-Code#5313), but closing and reopening the file resolves it.
Nice! Every change that removes implicit
This is one of the reasons I filed this issue. Kotlin addresses this at the interface level by making immutable lists covariant and mutable lists invariant: expect interface MutableList<E> : List<E>, MutableCollection<E>
expect interface List<out E> : Collection<E> |
@rubenferreira97 Thanks for your kind answer, but you know I mean that no runtime error should be happen if I never declare dynamic type actively or inferred by dart self. I dont know how can I extract the parameter's type in a function, but using a class can do what they call "type mirror" for this. Look this: class MyClass<T> {
List<T> value;
testFunc(T val) {
value[0] = val;
return val;
}
MyClass(this.value);
}
void main () {
testFunc <T> (List<T> list, T value) {
list[0] = value;
return value;
}
List<String> abc = ['a', 'b', 'c'];
final inClass = MyClass(abc);
inClass.testFunc('abc'); // ok
inClass.testFunc(123); // compile-time error
String a = 'abc';
a = inClass.testFunc('abc'); // ok
a = inClass.testFunc(123); // compile-time error
testFunc(abc, 'abc'); // ok
testFunc(abc, 123); // runtime error
a = testFunc(abc, 'abc'); // ok
a = testFunc(abc, 123); // compile-time error
print(a);
}
|
|
I have used typescript before. It is a compile-time error without doubt when writing: function testFunc<T>(list: T[], value: T) {
list[0] = value
return value
}
testFunc(['a','b', 'c'], 123);
|
|
@rubenferreira97 wrote:
Yes, that's extremely tempting if starting from scratch. However, the discussion in your issue about this subtyping structure shows that it gets harder when existing code hasn't been written to work well with that design. By the way, the alignment isn't perfect: A method like So do you optimize for "cleanly non-mutating", or do you optimize for "greatest possible interface which is soundly covariant"? Conversely, consider a method like Of course, |
|
@Xekin97 wrote:
That's not quite true. All programming languages (except perhaps Coq's language Gallina, and a few other theorem proving languages) are striking a balance between checking programs statically and raising errors at run time. Out of memory is obviously undecidable in most languages, so it occurs at run time. Nobody is trying to handle division by zero statically, so that's a run-time error, too. Lots of languages (not including Dart) can have null pointer errors because the type system considers the null object to have all types. Kotlin null-safety can be violated via Java code, but also based on pure Kotlin mechanisms (see this paper). When the initial version of Dart was designed (years before I joined), a very controversial decision was taken with respect to the handling of variance: Every type variable in Dart is covariant, and every construct which is not statically guaranteed to satisfy the typing constraints is subject to a type check at run time. The motivation for this design was mainly simplicity. Java wildcards had been introduced a few years earlier (which is a sound approach to variance, of the kind known as use-site variance), but they were considered complex to read and write. Hence, Dart took this other path which is a lot simpler, but relies on run-time checks at locations like Note that Java and C# have chosen the exact same approach with arrays, and they use Anyway, as an amazing surprise to me, Dart hasn't given rise to many run-time type errors caused by the dynamically checked covariance, as far as we can see from the issues reported here. So I have to conclude that it works surprisingly well (that is, safely) in Dart code as it is written by this community. Nevertheless, I'd very much like to introduce support for statically checked variance in Dart, so I created #524 (yes, upvotes are very welcome! ;-). Similarly, #753 and #229 are proposals about use-site (in)variance, which can be used to treat existing classes with covariant type parameters invariantly, without changing those classes. For example: // Assuming use-site invariance, i.e., `exactly` modifiers on type arguments.
T testFunc<T> (List<exactly T> list, T value) {
list[0] = value;
return value;
}
void main() {
List<exactly String> abc = ['a', 'b', 'c'];
testFunc(abc, 123); // Compile-time error.
}If you use the type OK, that's enough about nice statically checked mechanisms that we could have (if they get enough support). |
|
Next, I'd describe a few ways to make the code safer using Dart of today. Here's the original example again (moving T test<T>(List<T> list, T value) {
list[0] = value;
return value;
}
void main() {
List<String> arr = ['a', 'b', 'c'];
test(arr, 'def'); // OK.
test(arr, 123); // OK at compile time, inferred as `test<Object>(...)`, throws.
}The main reason why covariance is introduced is that type inference is applied to both arguments simultaneously. We can force a separation by currying the function: T Function(T) test<T>(List<T> list) => (T value) {
list[0] = value;
return value;
};
void main() {
List<String> arr = ['a', 'b', 'c'];
test(arr)('def'); // OK.
test(arr)(123); // Compile-time error.
}With the curried declaration, the value of the type parameter is determined fully by the first argument, and the second argument will never give rise to any upper bound computation (which was causing the covariance in the first place). A similar effect can be achieved by using an extension method (because the list will now be the receiver rather than an argument, and the type of the receiver is fully determined before any of the arguments are considered). extension<X> on List<X> {
X test(X value) {
this[0] = value;
return value;
}
}
void main() {
List<String> arr = ['a', 'b', 'c'];
arr.test('def'); // OK.
arr.test(123); // Compile-time error.
}Another approach which can be used to avoid covariance related run-time checks (or to make them explicit and perform them safely) is to eliminate the variance in the first place by keeping all parts inside a scope where the type parameter is in scope: class A<X> {
final List<X> xs = []; // This is actually a `List<exactly X>`.
X? testWithCheck(Object? value) {
if (value is X) {
xs.add(value); // Statically safe.
return value;
}
return null;
}
X testWithType(X value) {
xs.add(value);
return value;
}
}
void main() {
var a = A<String>();
// `testWithCheck` accepts any argument, but returns null when the
// argument doesn't have the required type.
print(a.testWithCheck('def')); // 'def'.
print(a.testWithCheck(123)); // 'null'.
// `testWithType` only accepts an `X`.
a.testWithType('def'); // OK
// a.testWithType(123); // Compile-time error.
// However, we can use covariance at the next level.
A<Object> aObject = a; // OK, based on covariance.
aObject.testWithType(123); // OK at compile-time, throws.
}The point is that code inside the class
We can also move the typing out one extra step (as in Finally, we can emulate invariance in current dart: // ----------------------------------------------------------------------
// Declare `A` (plus helpers).
typedef Inv<X> = X Function(X);
typedef A<X> = _A<X, Inv<X>>;
class _A<X, Invariance extends Inv<X>> {
final List<X> xs = []; // This is actually a `List<exactly X>`.
X test(X value) {
xs.add(value);
return value;
}
}
// ----------------------------------------------------------------------
// Use `A`, presumably in a different library.
void main() {
var a = A<String>();
a.test('def'); // OK
a.test(123); // Compile-time error.
// We can also perform the operations directly, safely.
a.xs.add('ghi'); // OK.
a.xs.add(123); // Compile-time error.
X test<X>(A<X> a, X value) {
a.xs.add(value); // OK
return value;
}
test(a, 'jkl'); // OK.
test(a, 123); // Compile-time error.
// Covariance at the next level cannot happen: `A` is invariant
// in its type parameter!
A<Object> aObject = a; // Compile-time error.
}The type alias Of course, a real invariance mechanism would be more convenient, but if you decide that you absolutely must make a particular class invariant in one or more type parameters then you can do it. |
|
@Xekin97 wrote:
function testFunc<T>(list: T[], value: T) {
list[0] = value
return value
}
testFunc(['a','b', 'c'], 123);Yes, this is a compile-time error in TypeScript. TypeScript uses invariance by default, which is the traditional approach that most languages use, and an approach that doesn't require any run-time type checks. TypeScript has a very different trade-off when it comes to typing, though. In particular, it does not maintain a type correct heap (as opposed to Dart), and this means that you can't actually rely on having objects of type function testFunc<T>(list: T[], value: T) {
list[0] = value;
var x: any[] = list;
x[0] = 123;
return value;
}
testFunc(['a', 'b', 'c'], 'd')The list T testFunc<T>(List<T> list, T value) {
list[0] = value;
List<dynamic> x = list;
x[0] = 123;
return value;
}
void main() {
testFunc(<Object>['a', 'b', 'c'], 'd'); // OK.
testFunc(['a', 'b', 'c'], 'd'); // Throws.
}In general, as you may have noticed, the treatment of variance in Dart is a big and complex topic. As I mentioned, I'll be very happy if and when we get support for statically checked variance in Dart (#524, #229). On the other hand, there are techniques which can be used to work with dynamically checked covariance such that there are no run-time type errors in practice, and many of those techniques come rather naturally (which is the reason why #524 can list about 25 issues about dynamically checked covariance, not 2500). I hope this helps! |
|
Interestingly, while compiling extension methods, dart "fixes" the type and doesn't attempt to widen it. In theory, it could - after all extension <T> on List<T> {
f(T x)=>0;
}
void main() {
[1,2].f("a"); // ERROR: The argument type 'String' can't be assigned to the parameter type 'int'.
} So writing |
|
@eernstg Thanks for such a detailed explanation.
I understand your opinion and absolutely agree, and I consider that it is not crash to my say.
You know, it is so difficult to find a bug in your code when only a runtime error happens but without any alerts in your IDE. I can only find it by the error stack layer by layer. What I mean is if I actively declare a Especially in teamwork, for an example: // This class might be implemented by the other third package
class Target<T> {
T current;
set (T value) {
current = value;
}
Value(this.current);
}
// This variety might be imported from other where
final tar = Target('');
// An unsafe util method, but pass tests and looks reasonable
setTargetValue <T>(Target<T> target, T value) {
target.set(value);
// insert some code here
print("set value success");
}
void main () {
setTargetValue(tar, 'abc'); // no compile-error
setTargetValue(tar, 123); // no compile-error
setTargetValue(tar, {}); // no compile-error
setTargetValue(tar, []); // no compile-error
}In this example, there are no fault alerts, and we never use the Another example: // ... same as prev
// Now it is safe
Function(T value) setTargetValue<T> (Target<T> target) {
return (value) {
target.set(value);
print("set value success");
};
}
dynamic getSafeValue() {
return 'text'
}
dynamic getUnsafeValue() {
return 123;
}
void main () {
final safeValue = getSafeValue();
final unsafeValue = getUnsafeValue();
setTargetValue(tar)(safeValue); // ok
setTargetValue(tar)(unsafeValue); // runtime error
}In this example, there is a runtime error, but we know the passed value is a @eernstg Your explanations and suggestions are helpful and clear, thank you very much. Ask for your understanding, I don't know much about type detection in static languages yet, so I can only see from a developer's perspective. |
|
@tatumizer wrote:
It would actually make a difference, though somewhat subtle. The point is that void main() {
var xs = <int>[];
List<num> ys = xs; // OK.
// The following will succeed.
assert(xs is List<exactly int>);
assert(ys is! List<exactly num>); // The type argument is actually `int`, not `num`.
}The on-type of an extension matters during applicability checks: extension<X> on List<exactly X> {
void foo() => print('foo!');
}
void main() {
List<exactly int> xs = [1]; // OK, inferred as `<int>[1]`.
List<int> ys = xs;
xs.foo(); // OK.
ys.foo(); // Compile-time error, no such member.
}With the use-site invariance feature, the type of a collection literal will always have an exact type argument. This is the most precise type we can give to the resulting object, which should then also be the type which is given to the object at the very beginning of its lifetime. We shouldn't have to test or cast in order to get the best type. So We would probably have a lint to flag locations where a non-covariant member like |
|
@Xekin97 wrote:
Right, and it's even worse when the run-time error doesn't happen (but some customer out there gets hit by it all the time). Here's the declaration again: // An unsafe util method, but pass tests and looks reasonable
void setTargetValue<T>(Target<T> target, T value) {
target.set(value); // Danger! Non-covariant member, receiver may well be covariant.
print("set value success");
}The fact that Dart uses dynamically checked covariance won't change right now. I actually expect that we will have support for statically checked variance. However, lots of code will probably still rely on dynamically checked covariance—because it is so convenient. So Dart developers will need to take special care around non-covariant methods (like There are a couple of reasons why
The whole thing starts and ends with "has a non-covariant member", and the other points are reasons why a covariant typing is likely to arise (at least at some call sites). One rule of thumb that you might want to keep in mind is that mutation of an object should be encapsulated. If you're creating an instance of When the object is passed to clients (if at all), they should use it in a read-only manner. This means that covariant typing is not a problem, and you don't have to worry about type parameters that occur in multiple parameter types, and all those sort of things. You may still have a situation where the use of a function like // This class might be implemented by the other third package
class Target<T> {
T current;
Target(this.current);
bool _isCovariant<X>() => <T>[] is List<X> && <X>[] is! List<T>;
void set(T value) => current = value;
}
extension<X> on Target<X> {
// This must be an extension method because we need to use the
// static type of the given `Target`.
bool get isCovariant => _isCovariant<X>();
}
// A util method that calls `Target.set` unsafely, but guarded by a test.
void setTargetValue<T>(Target<T> target, T value) {
if (target.isCovariant) {
try {
target.set(value);
print('Success, by sheer luck!');
} catch (_) {
print('Failure');
}
} else {
target.set(value);
print("Success");
}
}
// This variety might be imported from other where
final tar = Target('');
void main() {
setTargetValue(tar, 'abc');
setTargetValue(tar, 123);
setTargetValue(tar, {});
setTargetValue(tar, 'abc' as Object);
}We can't directly compare type variables in Dart, but You can detect all non-covariant members of a given class: The experiment // Assumes `--enable-experiment=variance`.
class Target<out T> {
T current; // Error.
Target(this.current);
void set(T value) => current = value; // Error.
}Note that In the typical case it's very easy to see whether a given signature is non-covariant: It uses a type variable as the type of a parameter. However, |
|
@Xekin97, thanks for the interesting and useful input! I think we can close this issue now. There are lots of interesting elements in this discussion, but they will all be preserved (whether or not the issue is closed). I don't think there is anything actionable that we can do at the language level, other than pushing on #524 and #229 and the like, and those issues already exist. So I'll close this issue now. Please create a new one if something still needs to be resolved. |
|
To note that @rubenferreira97 wrote:
The VSCode issue was closed today and the latest Insiders build has the fix. It should probably be fixed on the next stable release too. |
Why does a function not check the type of a passed parameter when it is not assigned to any variable?
This prevented many of my utility functions from getting accurate type error warnings when used by dart developers, but they still reported errors at runtime.
The text was updated successfully, but these errors were encountered: