Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inherent type for mapping constructor with no contextually expected type #54

Closed
jclark opened this issue Apr 9, 2019 · 4 comments
Closed
Labels
Area/Lang Relates to the Ballerina language specification design/incomplete Part of design not yet worked out spec/improve Something that should be improved in the spec status/pending Design is agreed and waiting to be added
Milestone

Comments

@jclark
Copy link
Collaborator

jclark commented Apr 9, 2019

When a mapping value is constructed by a mapping-constructor-expr that occurs in a context where there is no contextually expected type, what should the inherent type be? e.g.

var x = { a: 1 };

There are two contradictory principles that might be applied.

  1. No contextually expected type is the same as a contextually expected type of any|error, which would imply inherent type would be map<any|error>, ie maximally permissive.
  2. The type of members should be inferred in the same way as the type of variables, which would suggest the inherent type was record { int a; } or perhaps record {| int a; |}.
@jclark jclark added design/incomplete Part of design not yet worked out Area/Lang Relates to the Ballerina language specification labels Apr 9, 2019
@jclark
Copy link
Collaborator Author

jclark commented Apr 9, 2019

Note that the inherent type plays a much more fundamental role in the language than it did previously (when it was called storage type), since it now controls typing.

@jclark
Copy link
Collaborator Author

jclark commented Apr 10, 2019

I think we need to distinguish the case where we are explicitly inferring the type from the expression (e.g. because var was used), from the case where we have a contextually expected type that allows anything.

@jclark
Copy link
Collaborator Author

jclark commented Apr 13, 2019

A related point is whether the inferred type should be open or closed.

@jclark
Copy link
Collaborator Author

jclark commented Apr 17, 2019

Conclusion after discussion was that the inferred type will allow each field have its own type and will be open to anydata.

@jclark jclark added the spec/improve Something that should be improved in the spec label Apr 17, 2019
@jclark jclark added this to the 2019R1 milestone Apr 17, 2019
@jclark jclark added the status/pending Design is agreed and waiting to be added label Apr 17, 2019
@jclark jclark closed this as completed in 0d4003e Apr 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area/Lang Relates to the Ballerina language specification design/incomplete Part of design not yet worked out spec/improve Something that should be improved in the spec status/pending Design is agreed and waiting to be added
Projects
None yet
Development

No branches or pull requests

1 participant