<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 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 class=""><br class=""></div><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 class=""><br class=""></div><div class="">Slava</div></body></html>