Some corrections for the section 13 (types) of the language spec

[DartBot]

This issue was originally filed by ief...@unipro.ru

---

1. Section 13.3.1

It should be clarified if the type alias declaration is a subject to common type validations (including availability of used types etc).

As a special case, it should be clarified what error will be produced if a typedef declaration refers to itself (typedef f(f); or typedef f f();).

2. Section 13.4
   This section states that "The supertypes of an interface are its direct supertypes and their supertypes".
   However, this definition of supertype relation given below (after the << definition) is more common and includes this definition. So the first definition looks useless and may be removed.

3. Please clarify if the "<<" relation applies to function types? E.g. if a function type f1 is a subtype of a function type f2 (as defined in 13.5) is it correct that f1 << f2 ? Formally speaking, there is no "direct supertype" relation for function types.

4. The following definition contains a typo: "T is a subtype of
   S, written T <: S, if [⊥/Dynamic]T << S." It should be "if [Dynamic/⊥]T << S

5. Section 13.5 Each function is a subtype of an interface Function. Possibly it should be "direct subtype"?

6. Section 13.5
   Nothing is said about influence of type parameters of function types on subtype relation. For example, what is the relation between f<int>(); and f<double>() (typedef f<T>();) ?

7. Section 13.7
   "Void is not an interface type" - shouldn't it be a normative text?

8. Section 13.8
   Last sentence of this subsection states that "It is a static type warning if Ai is not a subtype of [A1 , . . . , An /T1 , . . . , Tn ]Bi..." where Bi are type parameter bounds. Typo: Ai should be Ti.

9. Section 13.8 states it is a static type warning if a type parameter is not a subtype of a corresponding type parameter bound. Should the compile-time error be produced as well?

[floitschG]

Added Area-Language, Triaged labels.

[gbracha]

Set owner to @gbracha.
Added Accepted label.

[gbracha]

I've fixed the definition of substitution, since all uses assumed the reverse. This addresses (8) and (4).
(1) A type alias is just that - an alias for a type expression. No new rules are needed.
(2) Fixed.
(3) << does not apply to function types. If it did, it would be defined.
(5) possibly, but inessential.
(6) Trying to parse this; I take it you are concerned with type aliases for functions (not actual function types). These are simply aliases and can be replaced by their contents.
(7) Not particularly.
(9) If we wanted a compile time error, we'd say so.

---

Added Done label.