Null Safety: Sound non-nullable types with incremental migration (NNBD) #110

leafpetersen · 2018-11-28T02:30:38Z

leafpetersen · 2018-11-30T23:49:07Z

I've added a draft of the roadmap for this proposal, linked from the header comment.

yjbanov · 2018-12-08T00:23:55Z

@jmesserly I'm not sure how to constructively move the NNBD discussion from #125 here, because the my suggestion is all about linking the two issues. But I'll try:

I suggest that, as a first step, we introduce sound non-nullable types as part of immutable types (#125). This has several advantages:

It would be a non-breaking change: immutable types is a new feature so having them NNBD doesn't break any existing code.
It could have the biggest performance impact: if non-nullability is implemented such that many highly-used types can be inlined, such as double, int, bool, enum, String, we could significantly improve memory layout efficiency.
It would give us a chance to get the syntax and semantics right and educate users before rolling NNBD to the "normal" classes, which does require a bigger migration.

jmesserly · 2018-12-08T01:30:02Z

IMO, linking the two proposals would be counterproductive. We are working hard on NNBD, there is a lot of design & planning work going on. There aren't any major open questions on syntax or desired semantics. Linking the two would prevent us from pushing forward on NNBD, because immutable types has a lot of open design questions, and we'd have to delay work on NNBD until that's resolved.

(Also it could be confusing if different parts of the language treat int as having different non-nullability. It would be really nice if int always means non-null, and int? always means mean nullable. The NNBD proposal achieves that.)

yjbanov · 2018-12-08T01:34:39Z

That's fine too, it was just an idea. I don't have enough context to know how best to proceed, so if you believe that NNBD and immutables should proceed completely independently, then they should :)

jmesserly · 2018-12-08T01:47:36Z

Makes sense :). Yeah, we seem to be gathering a lot of momentum behind Leaf's proposal. It's really exciting! I think we'll be able to apply the many lessons of Strong Mode to NNBD, to make the migration as easy & rewarding as possible. (e.g. ideally it's non-breaking for code that isn't migrated. Until you turn on NNBD, you don't break. Once you turn it on, you have to fix some errors, but you gain some degree of null safety, even if everything else isn't migrated yet. Once everything in an app is migrated, then it has sound null safety. It's pretty neat.)

... which in this CL will always null. This is the first step when adding NNDB support as outlined in dart-lang/language#110 Change-Id: If3810bcaf1b73e70924f09d619e2a84e7d5ba8d6 Reviewed-on: https://dart-review.googlesource.com/c/86860 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

This adds code to ignore trailing `?` in `as` and `is` expressions because the trailing `?` may be part of the larger expression. At the moment, this change is a no-op, but will become active when a subsequent CL lands support for nullable types as part of dart-lang/language#110 Change-Id: I829d6aee0f11957ca9b5e143000005031649449f Reviewed-on: https://dart-review.googlesource.com/c/86960 Reviewed-by: Brian Wilkerson <[email protected]>

... as part of adding NNBD as outlined in dart-lang/language#110 This only supports parsing simple nullable types such as int? and List<int>? while subsequent CLs will add support for parsing more complex types. Change-Id: I3cc5c65d20bf3732a39cab0e823b2f7332342866 Reviewed-on: https://dart-review.googlesource.com/c/86961 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

... which in this CL will always null. This is another step when adding NNDB support as outlined in dart-lang/language#110 Change-Id: I3974fcb885c63be4af9d1007258383f3f8191ae0 Reviewed-on: https://dart-review.googlesource.com/c/87080 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

…tion type This only supports nullable return values of the form <identifier> '?' 'Function' '(' ... This is an increment CL in the ongoing effort to add nullable type support as outlined in dart-lang/language#110 Change-Id: I42febae9f88f7e4d8b05907988deab97c7a7425c Reviewed-on: https://dart-review.googlesource.com/c/87081 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

This adds support for nullable types of the form <identifier> '.' <identifier> '?' and <identifier> '.' <identifier> '?' 'Function' '(' ... This is an increment CL in the ongoing effort to add nullable type support as outlined in dart-lang/language#110 Change-Id: I526aecbe64bacbd442cea0b4c52d36ff23b0443b Reviewed-on: https://dart-review.googlesource.com/c/87083 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

This reverts commit 7720689. Reason for revert: Breaks parsing less common conditionals (e.g. b ? c = true : g();) Original change's description: > Add support for prefixed nullable type > > This adds support for nullable types of the form > > <identifier> '.' <identifier> '?' > > and > > <identifier> '.' <identifier> '?' 'Function' '(' ... > > This is an increment CL in the ongoing effort to add nullable type support > as outlined in dart-lang/language#110 > > Change-Id: I526aecbe64bacbd442cea0b4c52d36ff23b0443b > Reviewed-on: https://dart-review.googlesource.com/c/87083 > Reviewed-by: Brian Wilkerson <[email protected]> > Commit-Queue: Dan Rubel <[email protected]> [email protected],[email protected] Change-Id: Ib5e74b4aad239f561a33eae9d95dffa2693037f7 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://dart-review.googlesource.com/c/87282 Reviewed-by: Dan Rubel <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

…unction type This reverts commit 11d081d Reason for revert: Breaks parsing less common conditionals (e.g. b ? c = true : g();) Original change's description: > Add support for simple nullable type return value in generalized function type > > This only supports nullable return values of the form > > <identifier> '?' 'Function' '(' ... > > This is an increment CL in the ongoing effort to add nullable type support > as outlined in dart-lang/language#110 Change-Id: I99bce29619d4e448193e3c81fa86a982791b1f77 Reviewed-on: https://dart-review.googlesource.com/c/87283 Reviewed-by: Dan Rubel <[email protected]>

This reverts commit bc8c7cf Reason for revert: Breaks parsing less common conditionals (e.g. b ? c = true : g();) Original change's description: > Add support for parsing simple nullable types > > ... as part of adding NNBD as outlined in > dart-lang/language#110 > > This only supports parsing simple nullable types > such as int? and List<int>? while subsequent CLs > will add support for parsing more complex types. Change-Id: I49a21a85dca19241e3b23ed5c9fb6084e70f2000 Reviewed-on: https://dart-review.googlesource.com/c/87284 Reviewed-by: Dan Rubel <[email protected]> Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

leafpetersen · 2018-12-17T23:10:58Z

I've updated the header with some sub-issues for discussing specific topics.

... as part of adding NNBD as outlined in dart-lang/language#110 This only supports parsing simple nullable types such as int? and List<int>? while subsequent CLs will add support for parsing more complex types. Change-Id: I144858946cb115755af437299899c2631105bf8c Reviewed-on: https://dart-review.googlesource.com/c/87501 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

This reverts commit c5fd11b. Reason for revert: Conditional expression lookahead may modify the token stream Original change's description: > Add support for parsing simple nullable types > > ... as part of adding NNBD as outlined in > dart-lang/language#110 > > This only supports parsing simple nullable types > such as int? and List<int>? while subsequent CLs > will add support for parsing more complex types. > > Change-Id: I144858946cb115755af437299899c2631105bf8c > Reviewed-on: https://dart-review.googlesource.com/c/87501 > Reviewed-by: Brian Wilkerson <[email protected]> > Commit-Queue: Dan Rubel <[email protected]> [email protected],[email protected] Change-Id: Ie1f47e7384ff51159aa2ebeb21561455b8e6287f No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://dart-review.googlesource.com/c/87620 Reviewed-by: Dan Rubel <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

... as part of adding NNBD as outlined in dart-lang/language#110 This CL updates the parser to recognize two specialized comments at the beginning of a library of the form '//@NNBD' and '//@NNBD*' for use by the analyzer to aid developers when converting their libraries to be non-nullable by default. In addition, the AstBuilder now populates the generated analyzer AST with nullable type information. Change-Id: I80d221dd138973aa32f05bde631245d9ac6ee10f Reviewed-on: https://dart-review.googlesource.com/c/87540 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

... as part of adding NNBD as outlined in dart-lang/language#110 This only supports parsing simple nullable types such as int? and List<int>? while subsequent CLs will add support for parsing more complex types. Due to current parser limitations, it also only supports nullable types in a limited number of statements such as T? t; if (x is String?) {} In addition, address comments in * https://dart-review.googlesource.com/c/sdk/+/87880 * https://dart-review.googlesource.com/c/sdk/+/87881 Change-Id: Ife4afadc0b72906fc0c4e9b1977ad838041c2a84 Reviewed-on: https://dart-review.googlesource.com/c/87920 Reviewed-by: Brian Wilkerson <[email protected]> Commit-Queue: Dan Rubel <[email protected]>

leafpetersen · 2018-12-22T01:34:54Z

Added links to two new discussion issues in the header comment.

Timmmm · 2021-01-06T09:24:19Z

I, for one, am a fan of "if-vars" as it entirely solves this problem.

I don't think it entirely solves the problem. How do you use if-vars for code like this?

if (field == null) {
  throw ...
}
var x = field.foo;

Levi-Lesches · 2021-01-06T09:37:55Z

The author of that proposal included a "negative if-var", which covers exactly that case. It would look exactly like you wrote:

if (var field == null) {
  throw "Error, not allowed to be null";
}
var x = field.foo;

The gist is that when checking to see if an if-var is null (or when using is!), instead of creating a new variable in scope of the curly brackets, it creates a new variable outside the scope of the if statement, and requires that the "then" block exit abnormally (throws, returns, break, continue, etc.). It's an interesting idea, even though I have trouble getting over the non-intuitive scope. See my comment there for more about that.

derolf · 2021-01-06T09:54:37Z

Honestly, I think the language should be designed in a way to avoid using the ! whenever possible!

If devs are forced into using ! at "strange" places and to need to scratch their head, they will scratch their head once or twice and then just put ! whenever the compiler complains.

This is why I wrote a linter for a bigger TypeScript project that disallowed the usage of ! completely.

Timmmm · 2021-01-06T11:04:32Z

I have trouble getting over the non-intuitive scope

Yeah that is confusing. And var field == null is quite close to var field = null which also seems confusing. I think I'd still rather give up field/getter symmetry.

This is why I wrote a linter for a bigger TypeScript project that disallowed the usage of ! completely.

I'd say you wasted some time writing a linter! In any case this isn't a problem in Typescript because Typescript's null checking isn't sound. They just ignore this problem. For example the following code type checks fine but will throw a type error at runtime.

let i = 1;

class Foo {
    public get maybeString(): string | null {
        return ++i % 2 === 0 ? "Dave" : null;
    }
}

function maybeStringLen(f: Foo): number {
    if (f.maybeString === null) {
        return 0;
    }
    return f.maybeString.length;
}

let x = maybeStringLen(new Foo());

jodinathan · 2021-01-06T13:12:18Z

I, for one, am a fan of "if-vars" as it entirely solves this problem.

I don't think it entirely solves the problem. How do you use if-vars for code like this?
if (field == null) {
  throw ...
}
var x = field.foo;

I really think that this is a case for a new local variable:

final notNullField = field;

if (notNullField == null) {
  throw ...
}
var x = notNullField.foo;

I am also in favor for simple type and non-null scoped var:

// not null scoped var
if (field != null use notNullField) {
  var x = notNullField.foo;
}

// type scoped var
if (field is SomeClass use fieldAsSomeClass) {
  print(fieldAsSomeClass.foo);
}

the semantics don't bother me as long as I have some simple and intuitive as above

Timmmm · 2021-01-06T14:23:04Z

I really think that this is a case for a new local variable

But that is what we have to do at the moment. The point of this thread is to find better solutions.

if (field != null use notNullField) {
  var x = notNullField.foo;
}

Another case if-vars don't solve is multiple chained conditions. E.g. in Typescript you can easily do this:

if (field !== null && field.subfield !== null && field.subfield.subsubfield !== null) {
  doStuff(field.subfield.subsubfield);
}

Would you advocate this?

if (field != null use a && a.subfield != null use b && b.subsubfield != null use c) {
  doStuff(c);
}

Surely we can do better than that!

jodinathan · 2021-01-06T14:26:26Z

I really think that this is a case for a new local variable

But that is what we have to do at the moment. The point of this thread is to find better solutions.
if (field != null use notNullField) {
  var x = notNullField.foo;
}
Another case if-vars don't solve is multiple chained conditions. E.g. in Typescript you can easily do this:
if (field !== null && field.subfield !== null && field.subfield.subsubfield !== null) {
  doStuff(field.subfield.subsubfield);
}
Would you advocate this?
if (field != null use a && a.subfield != null use b && b.subsubfield != null use c) {
  doStuff(c);
}
Surely we can do better than that!

TS is a great language and a very good evolution of JS stuff, but I don't think we should try to strictly follow it.

your example could be simple as:

if (field?.subfield?.subsubfield != null use c) {
  doStuff(c);
}

Levi-Lesches · 2021-01-12T01:07:33Z

And with if-vars (positive if-vars -- the thread seems to agree that negative if-vars are too messy for the moment), that would be:

if (var field?.subfield?.subfield != null) {
  doStuff(subfield);
}

Also,

This has now launched in tech preview

I just noticed that all 14 tasks at the top of this issue are complete. (Well, one is not checked off yet but the issue it's linked to is closed.) Does that mean this issue is ready to be closed? Oh how far it's come.

derolf · 2021-01-26T13:20:14Z

At least, for private final fields, it should be sound to propagate the null-safety:

class Foo {
  ...
  final Bar? _bar;
  ...
  void baz() {
    if (_bar != null) {
      _bar.somemethod(); <-- is always safe here
    }
  }
}

jodinathan · 2021-01-26T13:27:49Z

At least, for private final fields, it should be sound to propagate the null-safety:
class Foo {
  ...
  final Bar? _bar;
  ...
  void baz() {
    if (_bar != null) {
      _bar.somemethod(); <-- is always safe here
    }
  }
}

and if not overridden in any other class in the same file/part

derolf · 2021-01-26T13:38:15Z

@jodinathan

and if not overridden in any other class in the same file/part

I know, it's not perfect. But, I am currently migrating a bigger Flutter project with 150k Dart LOC.

The most annoying piece are exactly these constructs where you have final nullable fields. Typical pattern is a widget wrapping some arguments:

class Bla extends StatelessWidget {
  Bla({this.text});
  final String? text;

  @override
  Widget build(BuildContext) => text == null ? SizedBox.shrink() : Text(text);
}

jodinathan · 2021-01-26T13:42:23Z

@jodinathan

and if not overridden in any other class in the same file/part

I know, it's not perfect. But, I am currently migrating a bigger Flutter project with 150k Dart LOC.

The most annoying piece are exactly these constructs where you have final nullable fields. Typical pattern is a widget wrapping some arguments:
class Bla extends StatelessWidget {
  Bla({this.text});
  final String? text;

  @override
  Widget build(BuildContext) => text == null ? SizedBox.shrink() : Text(text);
}

I agree.
One of the reasons that we are not migrating to NNBD is the non-null promotion issue

rrousselGit · 2021-01-26T13:58:44Z

Sealed classes or structures would make this a lot less painful

The problem exists because of inheritance. By being able to store state in an inheritance-free manner, the type-inference could be much better

In the end it isn't just about null-testing here. All kinds of testing suffer from the same issue, such as:

final Object something
...

if (something is MyClass) {
  (something as MyClass).doSomething();
}

derolf · 2021-01-28T09:30:44Z

While migrating a 150k project, I run into the following problem:

///
void foo<T>(T bar) {
  switch (T) {
    case String:
      break;
    case double:
      break;
    default:
      throw Exception('Unsupported type $T');
  }
}

If T is nullable, it throws, so how can I add nullable Ts to the case?

rrousselGit · 2021-01-28T09:52:40Z

You can do:

Type _typeOf<T>() => T;

if (T == _typeOf<String?>())

That will require to not use a switch-case though

lrhn · 2021-01-28T09:56:28Z

@derolf You cannot add nullable types to the switch. Only constants can be used as switch case expressions, and there is no syntax for creating constant nullable type literals.

You'll have to use a non-constant approach instead.
One alternative:

Type typeOf<T>() => T; // Helper function.
final Type _nullableString = typeOf<String?>();
final Type _nullableDouble = typeOf<String?>();
void foo<T>(T bar) {
  var type = T;
  if (type == String || type == _nullableString || type == double || type == _nullableDouble) return;
  throw Exception("Unsupported type $type");
}

This will allow you to check against any type.

I'd probably rewrite it to avoid the Type equality checks. If you want to support both String? and String, maybe just check that T is a subtype of String?. Then I'd do:

bool _isSubType<S, T>() => <S>[] is List<T>;
void foo<T>(T bar) {
  if ((_isSubtype<T, String?>() || _isSubtype<T, double?>()) &&
      !(_isSubtype<T, Null>()) {
    return;
  }
  throw ....
}

derolf · 2021-01-28T16:29:49Z

@rrousselGit @lrhn thanks for the hints, I am using T.toString() and switch on it. After fixing ~4000 nullability issues, the app now runs. Btw I tried to use the "migration tool", but had to completely revert it because it was adding way too many "!" everywhere.

So, I am fixing the tests now.

Does anyone has an idea how to run tests from Visual Code while passing --no-sound-null-safety to Dart???

Options:

Adding "@Dart = 2.11" to all tests -> doesn't work because the tests themselves are null safe
Environment variable to turn on "no-sound-null-safety"?
Something in pubspec.yaml to turn on "no-sound-null-safety"?
Some option in the visual code plugin?

derolf · 2021-01-28T17:11:40Z

.vscode/settings.json:

{
    "dart.flutterTestAdditionalArgs": [
        "--no-sound-null-safety"
    ],
}

Levi-Lesches · 2021-01-28T17:59:52Z

You cannot add nullable types to the switch. Only constants can be used as switch case expressions, and there is no syntax for creating constant nullable type literals.

Was there talk about having something like T is Object? a while ago? (I get that it still wouldn't fit in a switch-case, just curious).

olfek · 2021-02-16T16:37:04Z

Hello, when is this feature being released?

leafpetersen · 2021-02-17T05:50:49Z

This feature has been released in the beta channel and should land in stable shortly.

olfek · 2021-02-17T07:31:15Z

@leafpetersen What is shortly? Few days? weeks? months? I am looking to start a new web service project in Dart.

leafpetersen · 2021-02-18T01:50:33Z

@olfek I suspect that the PMs would be sad if I stole their thunder, so I think I'll leave it at shortly. :) The feature has been released in a beta build, and the general cadence of stable releases is public info, so you can draw your own conclusions.

That said, I would discourage you from starting a new project with null safety enabled unless you're fairly confident that you will not subsequently need to take on a dependency which is not yet null safe. We are strongly encouraging folks to migrate in "waterfall" order (dependencies first). Starting with a null safe app and then adding a non-null safe dependency will require you to jump through some hoops and switch back to unsound mode. So if you're expecting to not have many package dependencies (or you can validate that all of your expected dependencies already have null safe releases), then by all means, grab a beta-channel SDK and go for it, but otherwise I might suggest waiting until the package ecosystem has a bit more time to migrate.

mit-mit · 2021-02-22T12:50:34Z

Please see this blog post for our latest update on migrating to null safety:

https://medium.com/dartlang/preparing-the-dart-and-flutter-ecosystem-for-null-safety-e550ce72c010

mit-mit · 2021-03-03T19:06:51Z

As of Dart 2.12 -- launched to the stable channel today -- null safety is now available!
https://medium.com/dartlang/announcing-dart-2-12-499a6e689c87

gmpassos · 2021-03-08T09:10:27Z

What a nice thread, 2+ years of hard work! I'm enjoying Dart Null Safety, it's the future of modern languages. ;-)

leafpetersen added the feature Proposed language feature that solves one or more problems label Nov 28, 2018

leafpetersen self-assigned this Nov 28, 2018

mit-mit added the state-active label Nov 29, 2018

jmesserly mentioned this issue Dec 6, 2018

Statically tracked shared immutable objects #125

Open

har79 mentioned this issue Dec 12, 2018

"if not null" operators #131

Open

matanlurey mentioned this issue Dec 17, 2018

Users want to define union or union-like APIs #145

Open

leafpetersen mentioned this issue Jan 2, 2019

How should default parameter values work with NNBD? #156

Closed

munificent mentioned this issue Jan 11, 2019

Proposal for non-nullable types dart-lang/sdk#28619

Closed

31 tasks

mit-mit closed this as completed Mar 3, 2021

mit-mit added this to Language funnel May 27, 2024

mit-mit moved this to Done in Language funnel May 27, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Null Safety: Sound non-nullable types with incremental migration (NNBD) #110

Null Safety: Sound non-nullable types with incremental migration (NNBD) #110

leafpetersen commented Nov 28, 2018 •

edited

Loading

leafpetersen commented Nov 30, 2018

yjbanov commented Dec 8, 2018

jmesserly commented Dec 8, 2018

yjbanov commented Dec 8, 2018

jmesserly commented Dec 8, 2018

leafpetersen commented Dec 17, 2018

leafpetersen commented Dec 22, 2018

Timmmm commented Jan 6, 2021

Levi-Lesches commented Jan 6, 2021 •

edited

Loading

derolf commented Jan 6, 2021 •

edited

Loading

Timmmm commented Jan 6, 2021

jodinathan commented Jan 6, 2021

Timmmm commented Jan 6, 2021

jodinathan commented Jan 6, 2021 •

edited

Loading

Levi-Lesches commented Jan 12, 2021

derolf commented Jan 26, 2021

jodinathan commented Jan 26, 2021

derolf commented Jan 26, 2021 •

edited

Loading

jodinathan commented Jan 26, 2021

rrousselGit commented Jan 26, 2021 •

edited

Loading

derolf commented Jan 28, 2021 •

edited

Loading

rrousselGit commented Jan 28, 2021

lrhn commented Jan 28, 2021

derolf commented Jan 28, 2021 •

edited

Loading

derolf commented Jan 28, 2021

Levi-Lesches commented Jan 28, 2021

olfek commented Feb 16, 2021

leafpetersen commented Feb 17, 2021

olfek commented Feb 17, 2021

leafpetersen commented Feb 18, 2021

mit-mit commented Feb 22, 2021

mit-mit commented Mar 3, 2021 •

edited

Loading

gmpassos commented Mar 8, 2021

Null Safety: Sound non-nullable types with incremental migration (NNBD) #110

Null Safety: Sound non-nullable types with incremental migration (NNBD) #110

Comments

leafpetersen commented Nov 28, 2018 • edited Loading

leafpetersen commented Nov 30, 2018

yjbanov commented Dec 8, 2018

jmesserly commented Dec 8, 2018

yjbanov commented Dec 8, 2018

jmesserly commented Dec 8, 2018

leafpetersen commented Dec 17, 2018

leafpetersen commented Dec 22, 2018

Timmmm commented Jan 6, 2021

Levi-Lesches commented Jan 6, 2021 • edited Loading

derolf commented Jan 6, 2021 • edited Loading

Timmmm commented Jan 6, 2021

jodinathan commented Jan 6, 2021

Timmmm commented Jan 6, 2021

jodinathan commented Jan 6, 2021 • edited Loading

Levi-Lesches commented Jan 12, 2021

derolf commented Jan 26, 2021

jodinathan commented Jan 26, 2021

derolf commented Jan 26, 2021 • edited Loading

jodinathan commented Jan 26, 2021

rrousselGit commented Jan 26, 2021 • edited Loading

derolf commented Jan 28, 2021 • edited Loading

rrousselGit commented Jan 28, 2021

lrhn commented Jan 28, 2021

derolf commented Jan 28, 2021 • edited Loading

derolf commented Jan 28, 2021

Levi-Lesches commented Jan 28, 2021

olfek commented Feb 16, 2021

leafpetersen commented Feb 17, 2021

olfek commented Feb 17, 2021

leafpetersen commented Feb 18, 2021

mit-mit commented Feb 22, 2021

mit-mit commented Mar 3, 2021 • edited Loading

gmpassos commented Mar 8, 2021

leafpetersen commented Nov 28, 2018 •

edited

Loading

Levi-Lesches commented Jan 6, 2021 •

edited

Loading

derolf commented Jan 6, 2021 •

edited

Loading

jodinathan commented Jan 6, 2021 •

edited

Loading

derolf commented Jan 26, 2021 •

edited

Loading

rrousselGit commented Jan 26, 2021 •

edited

Loading

derolf commented Jan 28, 2021 •

edited

Loading

derolf commented Jan 28, 2021 •

edited

Loading

mit-mit commented Mar 3, 2021 •

edited

Loading