<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br>Sent from my iPhone</div><div><br>On 22 Mar 2017, at 09:43, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div><blockquote type="cite" class=""><div class="">On Mar 21, 2017, at 11:29 PM, Matt Whiteside 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=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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; float: none; display: inline !important;" class="">One point which was raised by a couple of different people on this thread (Brent Royal-Gordon, Jonathan Hull), which gave me some hesitation in voting in favor of this proposal, is that it might make more sense to leave things alone for the time being, with the understanding that scoped access will be solved in some more general way via submodules in the future.</span></div></blockquote></div><div class=""><br class=""></div><div class="">For what it's worth, I don't really agree with Jonathan Hull on this. If we're going to remove the band-aid, we might as well rip it off now; there's no reason to wait for people to write more code for us to break.</div></div></blockquote><div><br></div><div>Fair point, but I honestly do not see how the stated very strong burden of proof to revert previous proposals has been met. The new proposal does seem to do anything really to address the needs of those that have a legitimate use for scoped access and the current state of things does not make life impossible for people who want to use file based visibility only or mostly. I really want to avoid having another proposal like the one that removed argument labels from blocks (burying them from the type param) that is incomplete and supposed to get addressed, but still has not been almost a year later.</div><div><br></div><div>This proposal as it is does not feel complete and I do not think this helps it satisfy the burden of proof needed for this release.</div><br><blockquote type="cite"><div><div class=""><br class=""></div><div class="">My point was simply that the burden of proof is now on those proposing to revert SE-0025, and the core team shouldn't accept this proposal unless they are satisfied that the burden has clearly been met.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>