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] [Out of scope][Gibberish]

So sorry, I meant to delete Swift-evolution from the cc list but forgot. Apologies for the off topic post. > On 17 Oct 2016, at 10:12, Jeremy Pereira > wrote: > > >> On 14 Oct 2016, at 20:11, Ted F.A. van Gaalen via swift-evolution >>

Re: [swift-evolution] Import Conditionals

I believe there was a draft to merge all the "Libc" modules; let me see if I can find that. On Mon, Oct 17, 2016 at 3:06 PM Sean Alling via swift-evolution < swift-evolution@swift.org> wrote: > *Description* > > In an effort to both (1) reduce boilerplate code, and (2) promote > cross-platform

Re: [swift-evolution] Import Conditionals

I disagree. What about when you need to disambiguate? Currently you’d need to use ‘Darwin.connect(...)’ or ‘Glibc.connect(…)’. Merging them both in to one ‘Libc’ module would make that much easier. > On 18 Oct 2016, at 01:07, Sean Alling via swift-evolution > wrote:

Re: [swift-evolution] Import Conditionals

Yeah I saw that thread. I think (a) this is a better solution and (b) this is applicable for use cases other than specifically Glibc/Darwin. -Sean Sent from my iPhone > On Oct 17, 2016, at 19:01, Saagar Jha wrote: > > I believe there was a draft to merge all the "Libc"

[swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

I was just doing some googling, turns out there was a discussion about nesting protocols in other types that seemed to go positively a long time ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/016074.html

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

I like it! I haven’t thought through the ramifications regarding associated types yet though. Is your vision that each conforming type would have to provide its own nested type as specified by the protocol? Or could the protocol itself define a nested type and anything could use it? protocol

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] [Pitch] Nested types in protocols (and nesting protocols in types)

I want this feature. Both class in protocol and protocol in class could clean up many relationships but I think that a blocking concern is "How does this interact with generics?" Nesting types in generic types is already disallowed and how different is this feature from that? On Mon, Oct 17, 2016

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] Why doesn't removeLast() on Collection return an optional?

I understand, pull request has been made. https://github.com/apple/swift/pull/5333 > On 17 Oct 2016, at 23:20, Max Moiseev wrote: > > Hi Louis, > > I believe, sometimes there are situations where you know for sure that your >

[swift-evolution] Import Conditionals

Description In an effort to both (1) reduce boilerplate code, and (2) promote cross-platform reusability I propose that we implement the following Import Conditional Operators: `||` and `&&` Currently, import conditionals must be implemented like so: ``` #if os(Linux) || os(FreeBSD)

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] [pitch] "import" declaration, support for comma-separated modules

-1 - I don't like this. I never understood the desire for *extreme* vertical conciseness, it tends to make code less readable in general and definitely makes diffs a lot harder harder to read. On Sun, 16 Oct 2016 at 11:26 Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] [pitch] "import" declaration, support for comma-separated modules

-1. I disagree. Having one import per line is much more readable and maintainable especially when you have statements like `import func Framework.someMethod`. Being able to use `let a, b, c, …` doesn’t have to do anything with importing modules since those are completely different features of

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

Daniel, it's all right, "There are only two hard things in Computer Science: cache invalidation and *naming things*." -- Marcin On Fri, Oct 14, 2016 at 6:25 PM, Daniel Dunbar via swift-build-dev < swift-build-...@swift.org> wrote: > Let's not change this thread into a discussion of English. :)

Re: [swift-evolution] [Proposal] Enums with stored properties

I’ve wondered this for a while now. Why must enums implement RawRepresentable? -Kenny > On Oct 12, 2016, at 4:37 AM, Karl via swift-evolution > wrote: > > You can already use structs as raw types. You just have to implement the > RawRepresentable conformance

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] [pitch] "import" declaration, support for comma-separated modules

> Having one import per line is much more readable and maintainable This depends on how much importance you give to "import" declarations. If you feel they equally important as the rest of your code, I can understand why you would want to see them. I don't. My preference is to see as much of the

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

Two weeks ago there was a similar pitch here https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon–20161003/027643.html In general I’m in favor of this feature, but I don’t know any technical issues this might have or does already have. As I said in the other thread. I’m for nested

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

Extremely strong +1. I’ve got a bunch of Objective-C-style really long type names of the sort “MyProtocol”, “MyProtocolSomeTypeEnum”, “MyProtocolSomeOptionsEnum”, etc. It would be really nice to make those Swiftier. Charles > On Oct 17, 2016, at 12:59 PM, Karl via swift-evolution >

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] [Pitch] Nested types in protocols (and nesting protocols in types)

That’s also on the line: [https://github.com/apple/swift/blob/611fc78d28a5da97dd1bea40761b913b1077aef5/docs/GenericsManifesto.md#nested-generics](https://github.com/apple/swift/blob/611fc78d28a5da97dd1bea40761b913b1077aef5/docs/GenericsManifesto.md#nested-generics) --  Adrian Zubarev Sent with

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

You can use popLast, that does exactly that: https://github.com/apple/swift/blob/master/stdlib/public/core/BidirectionalCollection.swift#L213 Max > On Oct 17, 2016, at 1:14 PM, Louis D'hauwe via

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

on Mon Oct 17 2016, Louis D'hauwe wrote: > Regarding the removeLast() function on Collection: > > The current implementation > > is: >

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

I see, the really issue I'm trying to bring up is that removeLast() can easily fail (and result in a fatal error). And unless you read the documentation, that's not very obvious. Maybe another approach would be to make removeLast() throw an exception if the collection is empty? That way you can

Re: [swift-evolution] Why doesn't removeLast() on Collection return an optional?

Hi Louis, I believe, sometimes there are situations where you know for sure that your collection is not empty. Maybe you are already in the context where the check has been performed. In these cases there is no reason you’d have to pay the price of an emptiness check once again. Perhaps, it