<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 13, 2017, at 2:42 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 13, 2017, at 11:40 AM, John McCall via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""> - I feel like we're not boxing ourselves in too much to assume a layout of the generic requirements. Having a base offset already imposes a pretty steep compatibility requirement — e.g. even if we significantly generalized a type's generic signature, we would still need to store old requirements (when actually obeyed) in the appropriate places for the old signature, or else the old pattern just doesn't work at all. As long as we can extend that with more information later, we don't really suffer from making layout assumptions today.</span></div></blockquote></div><br class=""><div class="">Do you mean if we significantly generalized the schema for generic requirements, or if we changed the definition of a single type to be more general? I would rather the latter did not happen.</div></div></div></blockquote><div><br class=""></div>I mean changing the definition of a type to be more general, and I think it's probably inevitable. I mean, we're already anticipating at least generalizing things to accept move-only types, although that at least has the advantage of not corresponding to a change in runtime protocol conformances.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Accessing generic arguments efficiently is important for extension methods, I think. In fact right now even thin functions recover metadata from a thick metatype argument if its the last parameter, although perhaps this is not intentional.</div></div></div></blockquote><br class=""></div><div>We recover metadata from all arguments, I think, unless it's a protocol witness.</div><div><br class=""></div><div>John.</div><br class=""></body></html>