Coder Social home page Coder Social logo

Comments (4)

rrousselGit avatar rrousselGit commented on September 27, 2024 2

I assume your scenario would be solved with the "variance" feature.
There's an experiment that allows writing code such as:

class Foo<in T> {}

class Bar<out T> {}

It adds extra restrictions on how a generic is used. I'm not familiar enough with the experiment, but I assume it could prevent assigning Task<int> to Task<int?>

from language.

Ing-Brayan-Martinez avatar Ing-Brayan-Martinez commented on September 27, 2024 2

Greetings, I have also had similar problems, this has an explanation, it turns out that the T type can sometimes behave like the Object type. If we review the fundamentals, all the objects that exist inherit from the Object class, this is equivalent to type Any in Typescript therefore it is impossible to determine the type because it is too generic

My recommendation is to avoid at all using types that can be null, in case it is unavoidable use the Optional type to keep the null value wrapped and keep it controlled. I personally made a proposal to introduce the Optional type specifically for cases like this

from language.

rrousselGit avatar rrousselGit commented on September 27, 2024

That's "expected" I think.
int is assignable to int?. So Task<int> is assignable to Task<int?>.

Generics have a few gotchas, especially when we downcast a generic class.
A more common example would be:

List<Object?> list = <int>[]; // valid
// Technically valid too. String is an Object?
// But will throw at runtime.
list.add("string"); 

from language.

lrhn avatar lrhn commented on September 27, 2024

The issue here is not nullability, it's contravariance. As @rrousselGit says, the only real solution is the "variance" feature which allows a type parameter to be declared contravariant or invariant.

Until then, Dart's unsafe covariant generics allows you to write code that ends up calling a Task<int>.run with null, or a Task<int>.run with 3.14 (by doing Task<num> task = Task<int>(); task.run(3.14); with no nulls involved).

This is working as designed. There is no easy solution without introducing variance annotations. They'll happen if we can make them happen. It's non-trivial to add such declartions to existing code that wasn't written for them.

from language.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.