This syntax was only ever meant to set a default, not constrain adopters. But it is a behavior change. cc @huonw, @slavapestov.

Good point. Is it possible though?

To constrain adopters? There's a Swift 4 feature for that, but it isn't finished yet.

You can get 90% of the way there by adding a requirement var rawValue: String, though.

Good point! Will give it a go.

To set a new default in a refined protocol, use an associated type:

protocol Foo: RawRepresentable {
    associatedtype RawValue = String
}

I don't think the intent of the old behavior of typealiases that shadow a protocol was to set defaults or really do anything at all. It was unsound and unfortunately we had to break some marginally valid code in order to put this on a more logical foundation.

That just changes the default; it does not enforce it.

I'm not sure I understand then. If you want to set a default, you can use 'associatedtype'. To constrain adopters, you can use a 'typealias'.

A typealias doesn't constrain adopters. It's just another default (by being another candidate).

@slavapestov, @DougGregor, and I talked some offline and realized that

• it's not exactly clear what 3.0 was doing

• it's not exactly clear what 3.1 is doing

• master is trying to do the thing you want (a same-type constraint)

• it's not exactly clear what the right behavior is.

But here's a dummy example that both 3.0 and 3.1 accept where the typealias is not picked as the associated type:

protocol BaseProto {
  associatedtype Assoc
}
extension BaseProto {
  var assoc: Assoc? { return nil }
}

protocol SubProto: BaseProto {
  typealias Assoc = String
}

extension SubProto {
  var assoc: String? { return "abc" }
}

struct Foo: SubProto {
  typealias Assoc = Int
}

func test1<X: BaseProto>(_ x: X) {
  print(X.Assoc.self, type(of: x.assoc))
}

func test2<X: SubProto>(_ x: X) {
  print(X.Assoc.self, type(of: x.assoc))
}

let foo = Foo()
print(Foo.Assoc.self, type(of: foo.assoc))
test1(foo)
test2(foo)

This outputs

Int Optional<String>
Int Optional<Int>
String Optional<String>

which is pretty weird but clearly has some semantics. I'm not exactly concerned about a contrived case like this, but it's possible that someone accidentally made the types not match up, and we shouldn't break working code in 4.0's 3-mode.

I think at this point we're going to stick with the new behavior, which treats this as a constraint on the associated type and suggests you explicitly use a same-type constraint instead.