Re: [swift-evolution] final + lazy + fileprivate modifiers

That blog post starts out right away to say that it's a response to community feedback. Moreover, the scenario you describe was just as possible in 2014 as it is now. Finally, then as now, it's unclear why you consider documentation to be "not pretty." After all, your reader would need to consult

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

On Feb 16, 2017, at 1:27 PM, Sean Heber via swift-evolution wrote: > > Doesn’t this break down if you can pass a reference as a parameter to a pure > function? If that’s not allowed, I guess I must have missed it. Also this > seems to require the function has a

Re: [swift-evolution] final + lazy + fileprivate modifiers

I'm aware of this, but that's fairly a long time ago - before Swift was open source and had community feedback and before Swift was used widely among developers. To me, real-world use of the language has shown some flaws of missing a protected access control, mainly having to decide between

Re: [swift-evolution] final + lazy + fileprivate modifiers

https://developer.apple.com/swift/blog/?id=11 > On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution > wrote: > > How about removing fileprivate, getting Swift 2 meaning of private (as most > people here now suggest) and add additional @protected

Re: [swift-evolution] Swift 4, stage 2 starts now

On Feb 16, 2017, at 4:18 PM, Ted Kremenek via swift-evolution wrote: > Deferring ABI Stability from Swift 4 > > Given the importance of getting the core ABI and the related fundamentals > correct, we are going to defer the declaration of ABI stability out of Swift >

Re: [swift-evolution] final + lazy + fileprivate modifiers

How about removing fileprivate, getting Swift 2 meaning of private (as most people here now suggest) and add additional @protected annotation for those who want a more fine-grained solution: @protected private - members accessable only from the class/struct/enum/... and their extensions within

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I'm just going to point out to the documentation about pure functions in the D language which has an unusual but very practical take on enforcing purity. It's interesting, and it might also provide a list for things that might need be addressed in this proposal.

Re: [swift-evolution] Pitch: Replacement for FileHandle

> On Feb 16, 2017, at 8:26 PM, Jon Shier via swift-evolution > wrote: > > 1. Is there anything developers can do today to use FileHandle safely in > Swift? There doesn’t seem to be, which seems to me to justify rather extreme > measures to fix the problem. As it

Re: [swift-evolution] Does protocol support add to an object's size?

> On 15 Feb 2017, at 18:51, Daryle Walker via swift-evolution > wrote: > > I don't know how protocol support works. I asking because I want to maintain > the stride of an array being the total count times the stride of the element, > which would complicate nominal

Re: [swift-evolution] Sequence/Collection Enhancements

A question that comes up often and has also led to a few syntax suggestions revolves around Optionals of Collections or Sequences. Since they can easily arise through optional chaining, making optional sequences easier to use would be useful. Much could be accomplished post-SE-0143 by adding a

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sent from my iPad > On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >> wrote: >> >> While we’re bikeshedding, I’m going to add my two cents.

Re: [swift-evolution] Nil-rejection operator

I created this set of extensions so I could more easily deal with optionals in a context where I was already potentially throwing errors. extension Optional { func deoptionalize() throws -> Wrapped { switch self { case .some(let wrapped): return wrapped case

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution > wrote: > > While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat > because this might be controversial here. > > I think both ‘private’ and ‘fileprivate’ are unnecessary

Re: [swift-evolution] Pitch: Replacement for FileHandle

Having only recently run into issues with FileHandle throwing exceptions I can’t catch (luckily in a logging framework, so it’s not production code), I’ve only had the briefest of example of the frustration anyone trying to use it in Swift seriously must suffer. So there are probably

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 18:00, Slava Pestov wrote: > > >>> On Feb 16, 2017, at 5:15 PM, David Sweeris via swift-evolution >>> wrote: >>> >>> >>> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution >>> wrote:

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 5:15 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution >> > wrote: >> >> Now that I've thought more about it, I have

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 17:45, Ben Cohen wrote: > > >>> On Feb 16, 2017, at 5:38 PM, Slava Pestov wrote: >>> >>> On Feb 16, 2017, at 5:32 PM, David Sweeris via swift-evolution wrote: > On Feb 16,

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 5:38 PM, Slava Pestov wrote: > > >> On Feb 16, 2017, at 5:32 PM, David Sweeris via swift-evolution >> > wrote: >> >> >>> On Feb 16, 2017, at 5:17 PM, Ben Cohen >>

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 5:32 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 16, 2017, at 5:17 PM, Ben Cohen > > wrote: >> >> The win with mapping only the values is that the underlying hash table can

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 5:17 PM, Ben Cohen wrote: > > The win with mapping only the values is that the underlying hash table can > retain the same physical layout, just with different values in the slots, so > it can be done faster. Only if the mapped dictionary’s values

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 5:06 PM, David Sweeris wrote: > >> >> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution >> > wrote: >> >> Hi swift-evolution, >> >> Following up on Ted’s post regarding the

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution > wrote: > > Now that I've thought more about it, I have a question. Escaping/unescaping > is an important concept to have in the language: if the API provider makes > the promise that a closure is

Re: [swift-evolution] Dictionary Enhancements

> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution > wrote: > > Hi swift-evolution, > > Following up on Ted’s post regarding the opening up of stage 2, I’m starting > a thread to discuss improvements to the Dictionary type. > > Here is a list of commonly

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:51 PM, Slava Pestov wrote: > >> >> On Feb 16, 2017, at 4:50 PM, Slava Pestov > > wrote: >> >>> >>> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution >>>

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:50 PM, Slava Pestov wrote: > >> >> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution >> > wrote: >> >>> >>> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution >>>

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:44 PM, Slava Pestov via swift-evolution > wrote: > >> >> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution >> > wrote: >> >> >>> On Feb 16, 2017, at 4:28 PM, Matthew

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:37 PM, David Waite via swift-evolution > wrote: > > >> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> As I have said elsewhere, I think the

[swift-evolution] Sequence/Collection Enhancements

Hi swift-evolution, Following up on Ted’s post regarding the opening up of stage 2, I’m starting a thread to discuss additive algorithms for Sequence and Collection. Here is a list of commonly requested algorithms to operate on Sequence or Collection: In-place transformations: transform

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:28 PM, Matthew Johnson via swift-evolution > > wrote: > > As I have said elsewhere, I think the mental anguish mostly derives from the > fact that scoped private is not the right “default” in a language that

[swift-evolution] Dictionary Enhancements

Hi swift-evolution, Following up on Ted’s post regarding the opening up of stage 2, I’m starting a thread to discuss improvements to the Dictionary type. Here is a list of commonly requested changes/enhancements to Dictionary, all of which would probably be appropriate to put together into a

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

Sent from my iPad > On Feb 16, 2017, at 5:40 PM, Karl Wagner wrote: > > >>> On 17 Feb 2017, at 00:26, Matthew Johnson wrote: >>> >>> On Feb 16, 2017, at 5:13 PM, Karl Wagner wrote: > On 17 Feb 2017, at

[swift-evolution] Swift 4, stage 2 starts now

Back in July, we laid out a plan for Swift 4 which divided the release into two stages. Since then, we’ve been in Swift 4 stage 1, which is characterized by the following text in the swift-evolutionrepository's README.md

Re: [swift-evolution] Pitch: Replacement for FileHandle

Please take off-topic discussion elsewhere. Thank you. > On Feb 16, 2017, at 3:35 PM, Maxim Veksler via swift-evolution > wrote: > > An off-topic suggestion on radar bugs: > > Instead of closing as "dupe" why not call it "merged" into a known issue ? > > Same

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 9:51 AM, Robert Widmann via swift-evolution > wrote: > > > >> On Feb 16, 2017, at 12:30 PM, Rien via swift-evolution >> wrote: >> >> In essence this is about assistance from the compiler that a function marked >>

Re: [swift-evolution] Pitch: Replacement for FileHandle

An off-topic suggestion on radar bugs: Instead of closing as "dupe" why not call it "merged" into a known issue ? Same technical result but very different IMHO user experience that allow communicating to the reporter that his bug hasn't simply been wrote-off as a "plus 1" but was combined into a

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

> On 17 Feb 2017, at 00:26, Matthew Johnson wrote: > >> >> On Feb 16, 2017, at 5:13 PM, Karl Wagner > > wrote: >> >> >>> On 17 Feb 2017, at 00:00, Karl Wagner >>

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 4:55 PM, John McCall via swift-evolution > wrote: > >> On Feb 16, 2017, at 5:42 PM, Sean Heber via swift-evolution >> wrote: >> Honestly I really think this should be seriously considered. I do use >> private and

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

> On Feb 16, 2017, at 5:13 PM, Karl Wagner wrote: > > >> On 17 Feb 2017, at 00:00, Karl Wagner > > wrote: >> >> >>> On 16 Feb 2017, at 23:44, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] Pitch: Replacement for FileHandle

I can scarcely think of a less productive or more disrespectful thing to do in a thread chock full of Apple engineers actively trying to help you out. They're just humans, led by other humans. They can't divine the presence of issues, just like they can't divine the priorities of individual tasks

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

> On 17 Feb 2017, at 00:00, Karl Wagner wrote: > > >> On 16 Feb 2017, at 23:44, Matthew Johnson via swift-evolution >> > wrote: >> >> I have been thinking a lot about enums and value subtyping lately and

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Now that I've thought more about it, I have a question. Escaping/unescaping is an important concept to have in the language: if the API provider makes the promise that a closure is non-escaping, the API client doesn't have to worry about the closure capturing variables and creating strong

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

> On Feb 16, 2017, at 5:00 PM, Karl Wagner wrote: > > >> On 16 Feb 2017, at 23:44, Matthew Johnson via swift-evolution >> > wrote: >> >> I have been thinking a lot about enums and value subtyping lately and >>

Re: [swift-evolution] Value Subtypes and Generalized Enums, a manifesto

> On 16 Feb 2017, at 23:44, Matthew Johnson via swift-evolution > wrote: > > I have been thinking a lot about enums and value subtyping lately and decided > to write down the ideas I’ve been thinking about. The result is a > manifesto-style document that explores

Re: [swift-evolution] final + lazy + fileprivate modifiers

The primary point of access modifiers is communication, with the secondary point of something like ‘internal’ or ‘final’ to be compiler optimization. Other languages do just fine with just having naming conventions for implementation details, rather than having the compiler enforce that

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 16, 2017, at 5:42 PM, Sean Heber via swift-evolution > wrote: > Honestly I really think this should be seriously considered. I do use private > and fileprivate and such myself *because it’s there* and as a result it feels > like I should - but I shudder to

[swift-evolution] Value Subtypes and Generalized Enums, a manifesto

I have been thinking a lot about enums and value subtyping lately and decided to write down the ideas I’ve been thinking about. The result is a manifesto-style document that explores a broad landscape of features that could eventually lead to proposals (at the right time, of course). I’m

Re: [swift-evolution] final + lazy + fileprivate modifiers

Honestly I really think this should be seriously considered. I do use private and fileprivate and such myself *because it’s there* and as a result it feels like I should - but I shudder to think how much brainpower I’ve wasted(?) on deciding which one to use when. I strongly suspect that the

Re: [swift-evolution] final + lazy + fileprivate modifiers

While we’re bikeshedding, I’m going to add my two cents. Hold on to your hat because this might be controversial here. I think both ‘private’ and ‘fileprivate’ are unnecessary complications that only serve to clutter the language. It would make a lot more sense to just have internal and public

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 15, 2017, at 1:34 AM, Dietmar Planitzer via swift-evolution > wrote: > > I do like approach #2. It would play well with extensions, look very familiar > to how private works in other main stream languages and it wouldn’t get in > the way of a possible

Re: [swift-evolution] final + lazy + fileprivate modifiers

I am glad you mention the "protected" scope. For me the private keyword is mostly just frustrating, precisely because I expect it to act in the way you describe "protected" - but it doesn't. This is probably because all of projects at my organisation (regardless of language) have files of about

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I think discovering them is not the problem, the question is if you really want them to be annotated pro-actively by the compiler - I don't think so. Your comparison with @escape is both right and wrong :) It's wrong in the sense that @escaping is a relaxing attribute while @pure is a

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 3:25 PM, Sean Heber via swift-evolution > wrote: > > Couldn’t pure functions be discovered by the compiler like how the compiler > already discovers an escaping vs. non-escaping function? Then perhaps pure > only needs to be an attribute on

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 10:24 PM, David Sweeris wrote: > > >> On Feb 16, 2017, at 13:10, Dennis Weissmann via swift-evolution >> wrote: >> >> Secondly, are they inherited? So if ClassA has a pure function a(), can I >> override it in subclass

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Couldn’t pure functions be discovered by the compiler like how the compiler already discovers an escaping vs. non-escaping function? Then perhaps pure only needs to be an attribute on closure parameter - just like how @escaping works? l8r Sean > On Feb 16, 2017, at 3:18 PM, T.J. Usiyan via

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 13:10, Dennis Weissmann via swift-evolution > wrote: > > Secondly, are they inherited? So if ClassA has a pure function a(), can I > override it in subclass ClassB: ClassA to be impure? (I think no) I would agree. IIUC, the "pureness" of A's

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I am ok with a keyword but `pure` in front of func doesn't work well with inline closures. A few people talked through many of these issues starting with this tweet. https://twitter.com/griotspeak/status/832247545325842432 On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull wrote: >

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

+1 for the idea of pure functions in swift. Seems like it would enable a lot of good optimizations (in some cases even just evaluating the function at compile time). -1 on the specific notation. I would much rather just put the word ‘pure’ in front of ‘func’, the same way we put ‘mutating'

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Big +1 from me for the concept, thanks for proposing this, here's some "but"'s that came to my mind after a quick read: I don't quite like the introduction of a new function arrow, in the end (in my opinion) this is just a more special, more constrained version of a normal function. For me,

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I held your opinion, although not terribly steadfast. Joe Groff convinced me that I was being pedantic with "'inout' is 'value goes in, value-prime goes out'" and the fact that it composes; you could use pure `+=` on a local value inside another pure function. The specific details of `inout` mean

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Thank you everyone. Since there does some to be interest, I have created a gist with some updates based on feedback. I have only incorporated the quickly integratabtle bits, so far. https://gist.github.com/griotspeak/31445ddcdba44bb8de599be6c9a93bd1 On Thu, Feb 16, 2017 at 3:03 PM, Nicolas

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

By its classic definition, a function that has inout parameters is not pure. So, again by classic definition, it should have a return value to have any use. But things can quickly get murky if we try to enhance and extend the meaning of pure. Then it becomes important to see at what level of

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> If it mutates whatever the input is referencing, it would have a side-effect which makes it "not pure" (for my understanding of what “pure” means). I am not really sure of it (I have not played around with it until now) but I don't think that this is an issue with the swift inout, cf.

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 11:27 AM, Sean Heber via swift-evolution > wrote: > > Doesn’t this break down if you can pass a reference as a parameter to a pure > function? If that’s not allowed, I guess I must have missed it. Also this > seems to require the function has

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

This looks cool. Quick nit-pick inline: > On 16 Feb 2017, at 18:03, T.J. Usiyan via swift-evolution > wrote: > > # Pure Functions > > * Proposal: > [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md > >

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

Doesn’t this break down if you can pass a reference as a parameter to a pure function? If that’s not allowed, I guess I must have missed it. Also this seems to require the function has a return value. I suppose generally a pure function without a return value wouldn’t make much sense - unless

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 15, 2017, at 10:57 PM, Rien wrote: > > > >> On 16 Feb 2017, at 03:45, David Smith wrote: >> >>> >>> On Feb 15, 2017, at 8:35 AM, Rien via swift-evolution >>> wrote: >>> On 15 Feb 2017, at 17:02,

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

+1 I think it's a very interesting proposal and here is why: - It improve readability by expressing intent. For example the difference between those two function, just by their signature, is obvious: func update(_ m: Class) -> Class and func update(_ m: Class) => Class The first one mutates

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I'm in favour of 'pure' functions, because they're a way of reducing the repetition of the kind of calculations you might want to perform in initialisers to convert argument values into property values. I don't know why "the function must have a return type" is seen as a requirement, though.

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 16, 2017, at 12:30 PM, Rien via swift-evolution > wrote: > > In essence this is about assistance from the compiler that a function marked > ‘pure’ is indeed pure? > I.e. an error message should be generated when a function marked as ‘pure’ is > in fact

Re: [swift-evolution] Pitch: Replacement for FileHandle

Just in case: https://www.openradar.appspot.com/radar?id=5046886029328384 On Wed, Feb 15, 2017 at 1:41 PM, Charles Srstka via swift-evolution < swift-evolution@swift.org> wrote: > On Feb 15, 2017, at 10:52 AM, Tony Parker > wrote: > > > Hi Charles, > > Have you

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

In essence this is about assistance from the compiler that a function marked ‘pure’ is indeed pure? I.e. an error message should be generated when a function marked as ‘pure’ is in fact not ‘pure’? If the answer to both questions is ‘yes’ then -not surprising- its a -1 from me. Unless there

[swift-evolution] [Pitch] Support for pure functions. Part n + 1.

# Pure Functions * Proposal: [SE-]( https://github.com/apple/swift-evolution/blob/master/proposals/-name.md) * Author(s): [TJ Usiyan](https://github.com/griotspeak) * Status: **Awaiting review** * Review manager: TBD ## Introduction Some functions are, essentially, only meant to be

Re: [swift-evolution] Pitch: Replacement for FileHandle

I agree that the current state of bug reporting through radars is unmotivating. We file these bug reports and have no idea if it even made a difference. After seeing this many times we just don't bother with bug reports. Sure I understand that internally apple uses duplicated issues to show how

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 16, 2017, at 8:21 AM, James Froggatt via swift-evolution > wrote: > > >> On 16 Feb 2017, at 02:13, Jordan Rose wrote: >> >> >>> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution >>> wrote:

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 16 Feb 2017, at 02:13, Jordan Rose wrote: > > >> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution >> wrote: >> >> Having loosely followed this discussion, the way I'm thinking of ‘closed’ is >> as a modifier which would

Re: [swift-evolution] Pitch: Replacement for FileHandle

I’m going OT here, but even though I understand your reasons, you need to acknowledge that for developers the rational thing to do is to not file radars at all. Any bug fix will get released at best a few months later and you can only actually take advantage of it a few years later (if you care

Re: [swift-evolution] final + lazy + fileprivate modifiers

On 16.02.2017 10:14, Goffredo Marocchi via swift-evolution wrote: I think it would be a step back as it again oversimplifies access control IMHO. If we touch access control we should aim to improve it from both a library implementation point of view but for a user point of view as well. +1. I