Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

> On 17 Oct 2016, at 19:47, Jonathan Hull wrote: > > First, let me say, thank you for your feedback. Just because I am arguing > against others' points does not mean that I don’t appreciate those points. > >> On Oct 17, 2016, at 12:37 AM, Rien wrote:

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

> On Oct 17, 2016, at 12:47 PM, Jonathan Hull via swift-evolution > wrote: > >> On Oct 17, 2016, at 12:37 AM, Rien > > wrote: >> >> -1. >> >> If an API designer wants to allow access to a “hidden’ member, he

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

First, let me say, thank you for your feedback. Just because I am arguing against others' points does not mean that I don’t appreciate those points. > On Oct 17, 2016, at 12:37 AM, Rien wrote: > > -1. > > If an API designer wants to allow access to a “hidden’ member,

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

> On Oct 16, 2016, at 8:19 PM, David Waite wrote: > > fileprivate (and internal, in a sense) are really in the “friend” camp. > Rather than declaring particular types are friends, these require code > locality - in the same file in the case of fileprivate, in the

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

Oops, correction: @unshelter(self); or @unshelter(aWotsit) // Inside a Wotsit or a Wotsit subclass this would work, y becomes available. Should be: @unshelter(aThing) // Inside a Wotsit or a Wotsit subclass this would work, y becomes available. On Mon, 17 Oct 2016 at 13:38 Jay Abbott

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

I'm not sure of my own opinions on this one as I can see good points on both sides. There also seem to be a variety of different discussions with similar concerns. So at the risk of confusing things I'm suggesting another idea, with the hope/intention of promoting some deeper thought and helping

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

-1. If an API designer wants to allow access to a “hidden’ member, he should be in control of that access. The proposed chance simply opens up access completely and leads to API vulnerability. (I am in favour of a “friend” solution, in which the API designer explicitly allows access to

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

> On Oct 16, 2016, at 7:23 PM, Xiaodi Wu wrote: > > On that last point, I would push back against calling it access inflation. If > a member needs to be visible outside the file for whatever reason, it needs > to have at least internal visibility. This is not at all

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

To put it more forcefully, I believe that ‘fileprivate’ currently suffers from the same problem that singletons do. That is, the main reason to make something ‘fileprivate’ instead of ‘private’ is to allow some sort of extension. It is highly unlikely that the point you were required to

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

No need to rename fileprivate; it's irrelevant to your use case and is resurrecting a bikeshedding discussion that really needs to be put to rest. The proposal is essentially for something like @testable for fileprivate members. Sounds fine to me. On Mon, Oct 17, 2016 at 09:35 Jonathan Hull via

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

> On Oct 16, 2016, at 3:28 PM, T.J. Usiyan wrote: > > I don't like this at all and it comes down to "what is hidden can also be > unhidden". This, to me, feels like it would create more confusion than it > would address. I don’t think it would cause confusion. Other

Re: [swift-evolution] Replace Fileprivate with Hidden + Import Hidden

I don't like this at all and it comes down to "what is hidden can also be unhidden". This, to me, feels like it would create more confusion than it would address. Why not just use `internal` for `hidden` items? If we're ok with modifying import statements, why not simply have a command that