<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=""><div class="">Hi Erica,</div><div class=""><br class=""></div><div class="">I think this proposal needs to address how allowing arbitrary identifiers to become declaration modifiers would work during parsing. Custom accessgroups may not be in the same file - or even module - as the code they effect, meaning that</div><div class=""><br class=""></div><div class="">foo</div><div class="">bar</div><div class="">func myFunction() {}</div><div class=""><br class=""></div><div class="">cannot be parsed into anything reasonable until we’ve first found all of the visible accessgroup declarations. It’s even worse when we do syntax-only parsing like we use for some IDE stuff (e.g. syntax colouring, code-folding). In that case we do not import any modules (not even the stdlib), and we are only looking at one file, not the full set of files in the module.</div><div class=""><br class=""></div><div class="">Ben</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 14, 2017, at 1:58 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Pull request: <a href="https://github.com/apple/swift-evolution/pull/681" class="">https://github.com/apple/swift-evolution/pull/681</a><div class=""><br class=""></div><div class="">Under the assumption that SE-0169 is adopted, Jeffrey B and I have been brainstorming about what a follow-on might look like. We want to address concerns that remain post-0169. Although this proposal is primarily additive, we feel it might just squeak in under Swift 4's gate as it targets potentially harmful language issues.</div><div class=""><br class=""></div><div class="">We appreciate your feedback about the substance of the proposal. At this time, we're not looking for bikeshedding on design details. We will welcome that once the question of whether the proposal is sufficiently substantive is settled. </div><div class=""><br class=""></div><div class="">Given the extremely limited timeline and the high volume of list traffic, we're looking for specific concerns (or benefits) you see in this pitch instead of a flurry of "+1" and "-1" responses . Our primary question regards whether this is a suitable approach (it is strongly influenced by SE-0077) and flexible enough to cover at least some outstanding concerns raised in list threads over the past weeks.</div><div class=""><br class=""></div><div class="">Thank you in advance for your feedback,</div><div class=""><br class=""></div><div class="">-- Erica</div><div class=""><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>