The second line fails because once you have a MyProtocol value, the compiler forgets where it came from, and so it could be some other type that conforms to MyProtocol. But the last line really ought to work! Sounds like more of the badness around protocols with superclass constraints.

cc @slavapestov

With asserts:

TYPE MISMATCH IN ARGUMENT 0 OF APPLY AT expression at [<stdin>:16:17 - line:16:32] RangeText="as MyProtocol).f"
  argument value:   %82 = alloc_stack $@opened("D2FA264A-7314-11E8-8817-9A0002AC2BC0") (MyProtocol) // type-defs: %81; user: %83
  parameter type: $@opened("D2FA264A-7314-11E8-8817-9A0002AC2BC0") (MyProtocol)

so it could be some other type that conforms to MyProtocol

Perhaps I'm not getting how where clause works – I thought it's kind of the same as regular inheritance, the outcome at least… I was going for a counter argument that the following works, but compiler also fails to build with a redundant conformance warning followed by a crash. Perhaps a separate issue?

Oops, my brain dropped the where clause from the first half of the answer. You're right, the compiler could allow that. Can we track that in a separate bug?

Separated into SR-8031 and SR-8032.

Protocol 'where' clauses don't support constraints on Self yet.