<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 Dec 14, 2015, at 4:59 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">We can evaluate this again at some point, but I don't want to "fan out" to having multiple working groups until we've had more experience with this process through Swift 3. In part, this is because of my experiences with the ISO C++ process. Particularly now, where there are a significant number of active subgroups in the C++ committee, it is very hard to even keep track of all of the different pieces under discussion, much less establish and maintain a coherent vision going forward. And that’s in a fairly mature language (C++) where the community has had a longer time to get a feel for what the language is; it’s harder for a younger language like Swift where the philosophy isn’t as widely understood.</div></div></blockquote></div><br class=""><div class="">Understood. C++ being more mature has more restrictions on what its subcommittees can really propose as changes to the language. This may make proposals harder, but likely helps them proceed in parallel. Swift likely has several more revolutionary releases ahead of it, and that makes it important to pool design into a few areas to try to increase their usefulness and composability.</div><div class=""><br class=""></div><div class="">-DW</div></body></html>