Informal proposal for strong mode toplevel inference #28218

leafpetersen · 2016-12-30T01:23:01Z

This is an informal specification of proposed changes to strong mode top level inference (#27499).

docs/language/informal/toplevel-inference.md

munificent

Couple small things here and there, but otherwise this looks really nice.

It might be worth talking a little about how this compares to the current implementation. Which parts are different? Which currently-inferred won't be with this and vice versa?

docs/language/informal/toplevel-inference.md

eernstg

Finally found a bit of time to finish the review. ;-)
Clearly, the rule that inferred and annotated types must be treated identically is the most controversial point.

docs/language/informal/toplevel-inference.md

eernstg · 2017-01-20T17:34:24Z

docs/language/informal/toplevel-inference.md

+   * The inference dependency of the identifier is itself if the identifier is
+      a candidate for inference.  Otherwise there are no inference dependencies.
+* A simple identifier denoting a formal parameter has the type with which it was
+  annotated.


If the declaration of the identifier is a parameter that doesn't have an annotation then the identifier isn't an IE.

stereotype441 · 2017-01-20T17:53:53Z

docs/language/informal/toplevel-inference.md

+   * No inference dependencies
+* A function literal with an expression body for which all parameter types are
+   type annotated and for which the return expression is an IE and has an
+   inferred type, has the corresponding function type.


We should clarify what happens if the function literal is declared with "async". I'm assuming that the return type should be Future<flatten(T)> (where T is the inferred type of the return expression, and flatten is as described in the spec).

Also, I notice that await ... expressions are not considered IEs. Is this intentional?

Added await and some other missing cases.

mit-mit · 2017-01-31T16:09:04Z

@leafpetersen can we land this?

scheglov · 2017-03-03T21:08:58Z

docs/language/informal/toplevel-inference.md

+   obvious type.
+   * No inference dependencies
+* An instance creation expression with no omitted type arguments has the
+   obvious type.


Is this item different than the previous one?

Duplicate. Done.

scheglov · 2017-03-03T21:11:09Z

docs/language/informal/toplevel-inference.md

+* A method invocation `o.m(...)` with no omitted type arguments where the
+   receiver is an IE with inferred type `T` such that `T` provides a signature
+   for `m` with return type `S` has type `S` (with any generic arguments
+   substituted in).


Are binary expressions handled as method invocations?
Is a + b handled as a.+(b)?
Will you specify additional logic for int + int, int + double, double + double, etc?

Are unary expressions handled as method invocations?

Yes. In general, the intention is that the inferred toplevel type should be the same as the inferred type in a local context. I added bullets for binary and unary expressions.

scheglov · 2017-03-03T21:17:33Z

docs/language/informal/toplevel-inference.md

+Top level inference has two phases:
+
+1. **Method override inference**
+    * If you omit a return type or parameter type from an overridden method,


What does exactly overridden method mean?

Added "or implemented". Intent is overriding a superclass method (including one from a mixin) or implementing an interface method. See the next section for more detail - are there specific things that I'm not capturing here or that are unclear?

There are fairly complex rules about methods overriding in the specification. I try to understand whether you indent that we follow all these rules, or whether we use simple 'find by name and infer formal parameter types one-by-one'.

Can you be more concrete about cases where the interpretation differs? Note I am not defining how inference behaves on erroneous cases such as defining a method with the same name as a field from a superclass, or defining a method with the same name as a superclass method with an incompatible signature. Those are errors: the tool can choose how best to handle surfacing those errors in a way that doesn't cause noise from cascading inference errors.

For example this code is not an error.
But what is the type of a in C?

class A { foo(num a) {} } class B { foo(double a) {} } class C extends A implements B { foo(a) {} }

That's intended to be addressed in the section below:

If there are multiple overridden/implemented methods and the type to be filled in does not agree, it is an error.

So your example is an inference failure error.

OK
The exact meaning of does not agree was not clear.
Now I understand what it means.
Thank you.

stereotype441 · 2017-05-28T15:45:10Z

docs/language/informal/toplevel-inference.md

+   * No inference dependencies
+* A simple or qualified identifier referring to a top level function, static
+   variable, field, getter; or a static class variable, static getter or method;
+   or an instance method; has the inferred type of the identifier.


Consider changing this to ...has the inferred type of the referent.

stereotype441 · 2017-05-28T15:46:18Z

docs/language/informal/toplevel-inference.md

+   an error.
+   * Note: specifically, references to instance fields and instance getters are
+     disallowed here.
+   * The inference dependency of the identifier is itself if the identifier is


Consider changing this to The inference dependency of the identifier is the referent if the referent is a candidate for inference...

stereotype441 · 2017-06-12T22:27:55Z

docs/language/informal/toplevel-inference.md

+  * Inference dependencies are those of the left hand operand.
+* A multiplicative binary expression is treated as a method call as defined in
+  the spec, with the same exceptions for when the left hand operand is of type `int`.
+  * Inference dependencies are those of the left hand operand.


This doesn't work for * and %, since the exceptions for when the left hand operand is of type int require us to know the type of the right hand operand; we can't know this type reliably unless the right hand operand is also an interface dependency.

A similar situation exists for + and -, which it looks like you forgot to cover (I don't see a bullet addressing additive expressions).

Suggestion: change this to:

A multiplicative or additive binary expression is treated as a method call as defined in the spec, with the same exceptions for when the left hand operand is of type int.

Inference dependencies are those of the left hand and right hand operands if the operator is *, %, +, or -.

Otherwise, inference dependencies are those of the left hand operand.

The informal spec for strong mode top level inference (#28218) says "If there are multiple overridden/implemented methods, and any two of them have non-equal types (declared or inferred) for a parameter position which is being inferred for the overriding method, it is an error." This CL fixes several SDK errors that arise from this rule. For example, the classes _Closure, Function, and Object contained members declared as follows: class _Closure implements Function { bool operator ==(other) ... } class Function { bool operator ==(Object other) ... } class Object { bool operator ==(other) ... } The type of Object's operator == was (dynamic) -> bool; the type of Function's operator == was (Object) -> bool; therefore the type of _Closure's operator == (which overrides both, since _Closure extends Object and implements Function) cannot be inferred and must be specified. A similar situation exists for _Double and _IntegerImplementation (both implement num, which declares operator == to have type (Object) -> bool), and _Uri (which implements Uri, which declares operator == to have type (Object) -> bool). This CL fixes the error by specifying the type explicitly in the classes _Closure, _Double, _IntegerImplementation, and _Uri. Change-Id: I91f7ceef8549399d438ba4be8c408493b3f338db Reviewed-on: https://dart-review.googlesource.com/28100 Reviewed-by: Vyacheslav Egorov <[email protected]>

stereotype441 · 2018-10-11T18:17:45Z

pkg/dev_compiler/tool/global_compile.dart

@@ -60,7 +60,7 @@ void main(List<String> args) {
    '--modules=legacy', // TODO(vsm): Change this to use common format.
    '--single-out-file',
    '--inline-source-map',
-    '-p',
+    '--packages',


Was this an accidental change? It doesn't seem like it belongs in this pull request

mit-mit · 2018-11-02T08:55:36Z

@leafpetersen can we merge this?

leafpetersen · 2018-11-02T16:56:07Z

We shouldn't merge it. I'd rather move this to the language repo. I'll sort it out next week and then close this.

Informal proposal for strong mode toplevel inference

9d715df

googlebot added the cla: yes label Dec 30, 2016

leafpetersen mentioned this pull request Dec 30, 2016

Specify strong mode "top level" inference #27499

Closed

leafpetersen requested review from munificent, lrhn, floitschG and eernstg December 30, 2016 01:26

leafpetersen mentioned this pull request Dec 30, 2016

Implement changes to strong mode top level inference #28219

Closed

bwilkerson reviewed Jan 3, 2017

View reviewed changes

docs/language/informal/toplevel-inference.md Show resolved Hide resolved

munificent approved these changes Jan 3, 2017

View reviewed changes

scheglov reviewed Jan 14, 2017

View reviewed changes

docs/language/informal/toplevel-inference.md Outdated Show resolved Hide resolved

scheglov reviewed Jan 14, 2017

View reviewed changes

docs/language/informal/toplevel-inference.md Outdated Show resolved Hide resolved

Address feedback 1

6407d5d

stereotype441 reviewed Jan 17, 2017

View reviewed changes

docs/language/informal/toplevel-inference.md Outdated Show resolved Hide resolved

eernstg reviewed Jan 20, 2017

View reviewed changes

stereotype441 reviewed Jan 20, 2017

View reviewed changes

Address more comments

fde62ae

scheglov reviewed Mar 3, 2017

View reviewed changes

leafpetersen added 3 commits March 7, 2017 11:26

Address comments from @scheglov

ade26bd

Additional clarifications

77fcf54

Clarify final field override inference

8f2be46

leafpetersen mentioned this pull request Apr 24, 2017

Dart 1.23 (strong mode) can not infer the type well #29437

Closed

leafpetersen mentioned this pull request May 12, 2017

Document Dart 1.5 strong mode #27530

Closed

stereotype441 reviewed May 28, 2017

View reviewed changes

stereotype441 reviewed Jun 12, 2017

View reviewed changes

kmillikin mentioned this pull request Apr 17, 2018

Using a toplevel variable changes inference results in CFE #32866

Closed

stereotype441 reviewed Oct 11, 2018

View reviewed changes

leafpetersen closed this Jan 11, 2019

leafpetersen deleted the prop-toplevel-inference branch January 11, 2019 21:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Informal proposal for strong mode toplevel inference #28218

Informal proposal for strong mode toplevel inference #28218

leafpetersen commented Dec 30, 2016

munificent left a comment

eernstg left a comment

eernstg Jan 20, 2017

leafpetersen Feb 28, 2017

stereotype441 Jan 20, 2017

leafpetersen Feb 28, 2017

mit-mit commented Jan 31, 2017

scheglov Mar 3, 2017

leafpetersen Mar 7, 2017

scheglov Mar 3, 2017

leafpetersen Mar 7, 2017

scheglov Mar 3, 2017

leafpetersen Mar 7, 2017

scheglov Mar 7, 2017

leafpetersen Mar 7, 2017

scheglov Mar 7, 2017

leafpetersen Mar 7, 2017

scheglov Mar 7, 2017

leafpetersen Mar 7, 2017

stereotype441 May 28, 2017

stereotype441 May 28, 2017

stereotype441 Jun 12, 2017

stereotype441 Oct 11, 2018

mit-mit commented Nov 2, 2018

leafpetersen commented Nov 2, 2018

Informal proposal for strong mode toplevel inference #28218

Informal proposal for strong mode toplevel inference #28218

Conversation

leafpetersen commented Dec 30, 2016

munificent left a comment

Choose a reason for hiding this comment

eernstg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mit-mit commented Jan 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mit-mit commented Nov 2, 2018

leafpetersen commented Nov 2, 2018