Spec: Refactoring: Merge "definitions" and "declarations". #18259
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
smarter
approved these changes
Aug 2, 2023
docs/_spec/04-basic-definitions.md
Outdated
| However, there is a restriction on forward references in blocks: | ||
| In a statement sequence ´s_1 ... s_n´ making up a block, if a simple name in ´s_i´ refers to an entity defined by ´s_j´ where ´j \geq i´, then for all ´s_k´ between and including ´s_i´ and ´s_j´, | ||
|
|
||
| - ´s_k´ cannot be a variable definition. | ||
| - If ´s_k´ is a value definition, it must be lazy. | ||
|
|
||
| Moreover, in a block, all definitions must be concrete, and opaque type alias definitions are not allowed. |
There was a problem hiding this comment.
It's not very useful, but abstract type definitions are allowed in blocks.
docs/_spec/04-basic-definitions.md
Outdated
| @@ -457,7 +452,7 @@ Variance annotations indicate how instances of parameterized types vary with res | |||
| A ‘+’ variance indicates a covariant dependency, a ‘-’ variance indicates a contravariant dependency, and a missing variance indication indicates an invariant dependency. | |||
|
|
|||
| A variance annotation constrains the way the annotated type variable may appear in the type or class which binds the type parameter. | |||
| In a type definition `type ´T´[´\mathit{tps}\,´] = ´S´`, or a type declaration `type ´T´[´\mathit{tps}\,´] >: ´L´ <: ´U´` type parameters labeled ‘+’ must only appear in covariant position whereas type parameters labeled ‘-’ must only appear in contravariant position. | |||
| In a type definition `type ´T´[´\mathit{tps}\,´] = ´S´`, `type ´T´[´\mathit{tps}\,´] >: ´L´ <: ´U´` or `type ´T´[´\mathit{tps}\,´] >: ´L´ <: ´U´ = ´S´`, type parameters labeled ‘+’ must only appear in covariant position whereas type parameters labeled ‘-’ must only appear in contravariant position. | |||
There was a problem hiding this comment.
Suggested change
| In a type definition `type ´T´[´\mathit{tps}\,´] = ´S´`, `type ´T´[´\mathit{tps}\,´] >: ´L´ <: ´U´` or `type ´T´[´\mathit{tps}\,´] >: ´L´ <: ´U´ = ´S´`, type parameters labeled ‘+’ must only appear in covariant position whereas type parameters labeled ‘-’ must only appear in contravariant position. | |
| In a type definition `type ´T´[´\mathit{tps}\,´] = ´S´`, `type ´T´[´\mathit{tps}\,´] >: ´L´ <: ´U´` or `opaque type ´T´[´\mathit{tps}\,´] >: ´L´ <: ´U´ = ´S´`, type parameters labeled ‘+’ must only appear in covariant position whereas type parameters labeled ‘-’ must only appear in contravariant position. |
docs/_spec/04-basic-definitions.md
Outdated
| A parameter signature consists of an optional type parameter clause `[´\mathit{tps}\,´]`, followed by zero or more value parameter clauses `(´\mathit{ps}_1´)...(´\mathit{ps}_n´)`. | ||
| Such a declaration or definition introduces a value with a (possibly polymorphic) method type whose parameter types and result type are as given. | ||
| Such a definition introduces a method with a type (if there is no type or term parameter clause) or methodic type whose parameter types and result type are as given (otherwise). |
There was a problem hiding this comment.
This sentence is hard to parse, are we distinguishing "method with a type" versus "method with a methodic type"? Could the former be called "method with a proper type" to avoid confusion?
docs/_spec/04-basic-definitions.md
Outdated
| @@ -580,11 +573,11 @@ A unary operator is a method named `"unary_´op´"` where ´op´ is one of `+`, | |||
|
|
|||
| ### Default Arguments | |||
|
|
|||
| Each value parameter declaration may optionally define a default argument. | |||
| Each formal value parameter may optionally define a default argument. | |||
There was a problem hiding this comment.
It looks like the spec uses both "formal parameter" and "parameter" interchangeably, either seems fine (as long as arguments are called arguments and not parameters), but it'd be preferable to stick to one terminology (e.g. just below "for every parameter").
Previously, abstract members were syntactically separate from concrete members, and referred to "declarations", as opposed to "definitions". In this commit, all of them become "definitions". There are abstract definitions and concrete definitions. They share their syntactic productions. This will allow to more easily introduce more kinds of definitions that can be abstract or concrete in deeper productions of the grammar, such as extension methods.
sjrd
force-pushed
the
spec-merge-definitions-and-declarations
branch
from
445c8e2 to
86d06b4
Compare
smarter
approved these changes
Aug 2, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, abstract members were syntactically separate from concrete members, and referred to "declarations", as opposed to "definitions".
In this commit, all of them become "definitions". There are abstract definitions and concrete definitions. They share their syntactic productions.
This will allow to more easily introduce more kinds of definitions that can be abstract or concrete in deeper productions of the grammar, such as extension methods.
Tentatively assigning to @smarter