> On 22 Mar 2017, at 10:53, Goffredo Marocchi via swift-evolution > <[email protected]> wrote: > > > Sent from my iPhone > > On 22 Mar 2017, at 09:43, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >>> On Mar 21, 2017, at 11:29 PM, Matt Whiteside via swift-evolution >>> <[email protected]> wrote: >>> >>> 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. >> >> 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. > > 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. > > 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.
Agreed with the general idea of incompleteness. I am less sanguine about the burden of proof. Imo there is no absolute and irrevocable proof needed to accept or reject a change proposal. I was under the impression that Swift should be treated as a living and evolving language, fitting and moulding itself to the need, desires and wishes of its users. Rejecting only on the basis of need would be too limiting imo. And that can be a problem in cases like these: an unliked feature that some people feel a need for. Rien. > >> >> 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. >> >> -- >> Brent Royal-Gordon >> Architechies >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
