Currently we forbid bounds on type parameters in structs, enums, and types.
So the following is illegal:

struct S<X: B> {
    f: ~T<X>,
}

We maintain soundness by checking bounds on fields when we instantiate a
struct. I believe the behaviour was changed to this so that there was only
one place to specify type bounds for impls/structs.

Although I don't think this approach is wrong (or unsafe), it sits badly
with me for several reasons:
1. The main reason is that it means we have two ways to type check generic
types. For traits, functions, and methods we check based on bounds where
the item is declared. For structs, enums, and types, we check based on
where the type variable is used and check where the item is used. That is
in the first case we check the polytype, and in the second case we check
the instantiation of a polytype. I think it is confusing for programmers
and inelegant to have these two methods for checking in one language.

2. It means we can create impls which have access to just part of a struct.
E.g.,

trait B {}
trait T<X: B> {}
struct S<X> { f: ~T<X> }
impl<X> S<X> {...}

Since X in the impl is not bounded by B, the field f has malformed type. I
hope any attempts to use it would not type check. I think this is a
confusing situation to be in for the programmer - you can write an impl
that it is not possible to use because of something deep in the type S.

3. I am adding the `unsized` (or possibly `type`) keyword to the language.
This may be added to any formal type parameter, including on structs.
Indeed it seems important to allow its use on structs. So the unsized
modifier will be checked in the style of bounds on params for traits for
all uses. I think this adds to the confusing type checking of type params
between structs and traits (and so forth).

Does anyone share my concerns? Or are these outweighed by the benefits? Are
there benefits I'm not aware of? Other thoughts?

Thanks, Nick
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to