-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
spec: "strictly comparable" and "type constraints". #59104
Comments
CC @griesemer
|
The issue is not about defining the comparability of interface types that are not basic, but rather about maintaining consistency in terminology. If "a type is strictly comparable if it is comparable and not an interface type," then how can a "strictly comparable type constraint" exist when a type constraint is an interface?
The point is to clarify that in this instance type parameters obtain their type sets from Type constraints (interfaces types that are strictly comparable, as apposed to type argument, such as interface type arguments which are not strictly comparable)
In my opinion, the way the word "comparable" is used in the specification strongly suggests a domain-specific term. Its meaning is not immediately obvious (the document even links it to "Comparison Operators"), so I don't see any issue in treating it as a capitalized term. Alternatively, you could write "comparable type." In any case, the goal is to help the reader keep track of which "comparable" is being discussed.
Why? Why is it necessary to define the type set of
which is exactly:
|
I see, I missed that you changed the text from referring to a "type parameter" to referring to a "type constraint." I do think that it's important to define when a type parameter is strictly comparable. It's not clear to me whether it is important to define when a type constraint is strictly comparable. Your suggested modified text doesn't explain when a type parameter is strictly comparable. Or so it seems to me.
Are there other such capitalized terms in the spec today? If not, let's not add one.
The definition of the type set of |
Well, the spec does mention the term "strictly comparable type constraint," so it begs the question, what is it?
The spec states: "An interface type defines a type set". The spec states: "Type parameters are strictly comparable if all types in their type set are strictly comparable." This implies that type parameters are strictly comparable if all the types in the type set defined by their type constraints are strictly comparable. What do you call a type constraint that defines a type set where all types are strictly comparable other than a strictly comparable type constraint?
Agreed, so I suggest using the term "comparable types" linking to the "Comparison Operators" section: Compare: Original: "Even though interfaces that are not type parameters are comparable, they are not strictly comparable and therefore they do not implement comparable. However, they satisfy comparable. vs. Revised: Even though interfaces that are not type parameters are comparable types, they are not strictly comparable and therefore they do not implement the comparable interface. However, they satisfy the comparable interface.
It seems to me that |
Yes.
The spec is intended to be readable but it is not a tutorial. I'll leave the other points for @griesemer . |
Please consider the following revised statement: "Type constraints are deemed strictly comparable if their elements are strictly comparable and the comparable interface is not included. In this case, the associated type parameters are also considered strictly comparable." This occurs because incorporating the comparable interface in a type constraint effectively relaxes the constraint, allowing any comparable type as a type argument provided that it implements all other interfaces included in the type constraint. |
Marked for 1.21 so it remains visible. Not sure yet if we need to make any changes. |
#1 According to the Language Specification:
Consider changing to:
Rational: By definition “A type constraint is an interface” and the doc explicitly mentions: “strictly comparable type constraint” under "Satisfying a type constraint".
#2 Consider capitalizing each instance of the word "Comparable" where it references the property of comparability, as described in the "Comparison Operators" section. The term "comparable" appears in other contexts, such as "strictly comparable" and the comparable Interface", so due to the repetition of the word, it can be difficult to follow.
#3 Addressing a related but distinct issue, under "General Interfaces" it is stated that: "The type set of a non-interface type term is the set consisting of just that type."
The following example is provided:
By definition, this interface is a non-basic interface, which means it can only appear in type constraints. However, the rationale for an interface of this form is not immediately apparent. Please clarify in the spec the circumstances in which declaring an interface with a non-interface type term would be sensible.
The text was updated successfully, but these errors were encountered: