Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

I encountered this precise memory leak in my code a few days ago, so I sympathize. A second solution would be to drop function references. I think a core team member suggested it on another thread. > On 3 Mar 2017, at 22:27, Josh Parmenter via swift-evolution >

Re: [swift-evolution] Random

While I am not against the idea, I believe that this is not as easy as one would think as everyone has a different understanding of the word "random" as most of random generators aren't "true" random generators. I think this would ideally require a new protocol RandomGenerator which would be

[swift-evolution] Random

This is a small improvement, but I still think it is worthwhile. I would like to see an 'init(randomIn: Range)’ added to Numeric (where Comparable), which would return a random number in the given range. It is something I have added myself to a subset of number types, but it really should be

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution > wrote: > > > I’ve read through the last couple of Swift (sub)Module proposals put forward, > and since my particular use-cases for a sub-module solution seemed to be > under-served by them, I’ve

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 3, 2017, at 1:13 PM, Karim Nassar wrote: > >> >> On Mar 3, 2017, at 12:35 PM, David Hart > > wrote: >> >>> >>> ### Making a Sub-module >>> >>> To create a sub-module within a Module (or sub-module) is simple: The

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

Honestly, I think this is one of the rougher parts of the language to see problems in. In my opinion, anything that can be done to either warn of retain cycles or enforce a better practice in this would be valuable. Josh On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution

[swift-evolution] Should explicit `self.` be required when providing method as closure?

Hi list members, During code review today, I noticed a really subtle memory leak that looked like: self.relatedObject = RelatedObject(callback: relatedObjectDidFinish) Where `relatedObject` is a strong reference, `callback` is an escaping closure, and `relatedObjectDidFinish` is a method

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

> On Mar 2, 2017, at 10:52 PM, T.J. Usiyan wrote: > > Submodules will, I hope, afford us the ability to share meaningfully arranged > API. In an ideal scenario, I could have a module that has all of the smaller > pieces of 'utilities and conveniences' that one builds up

Re: [swift-evolution] [Draft] scope-based submodules

> On Mar 2, 2017, at 10:08 PM, Brent Royal-Gordon > wrote: > >> On Mar 1, 2017, at 11:56 AM, David Hart wrote: >> >>> 2. Normally, references within the module to submodule symbols need to be >>> prefixed with the submodule name. (That is, in

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

That makes totally sense to me, but thank you John for further clarification. --  Adrian Zubarev Sent with Airmail Am 3. März 2017 um 21:30:11, John McCall (rjmcc...@apple.com) schrieb: On Mar 3, 2017, at 1:36 PM, Adrian Zubarev via swift-evolution wrote: I

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 1:36 PM, Adrian Zubarev via swift-evolution > wrote: > I actually found the source, and it’s even an official one. :) > >

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 1:26 PM, Adrian Zubarev > wrote: > > Can you check this translation, and maybe based on it’s (possible) mistakes > provide better examples in the next proposal draft on how one should think > with the new pure access model. > > open

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 11:26 AM, BJ Homer wrote: > > I agree that “scope(set: file)” reads better. It does make it a little > strange that “scope(set)" is also valid, though; it’s ambiguous whether it > takes labeled or unlabeled arguments. Under this proposal, all of these

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 1:12 PM, Adrian Zubarev > wrote: > > If I understand the model correctly, then classes structs and enums will have > an addition capability for their members. > > static = access(type) access(override, nowhere) > > class = access(type)

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

Can you check this translation, and maybe based on it’s (possible) mistakes provide better examples in the next proposal draft on how one should think with the new pure access model. open class A { open internal(set) var abc: Int = 42 public static func foo() {} open class

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

If I understand the model correctly, then classes structs and enums will have an addition capability for their members. static = access(type) access(override, nowhere) class = access(type) access(override, everywhere) You could combine type into one parameterized access, and make the

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

I actually found the source, and it’s even an official one. :) https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Declarations.html#//apple_ref/doc/uid/TP40014097-CH34-ID483 NOTE In a class declaration, the static keyword has the same effect as

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

> On Mar 3, 2017, at 9:56 AM, Tony Parker wrote: > > I’m concerned about the large source compatibility impact this change would > have. Even if we claim that it’s only for Swift 4, migration would be > difficult. Even if it were just a warning, that could be

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On 03 Mar 2017, at 18:54, Karim Nassar wrote: > > Thanks for your feedback. > > These are very fair concerns and point taken. There are other mechanisms we > could use to achieve similar ends, I’ll work on some additional ideas. > > How do you view the overall

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 3, 2017, at 12:35 PM, David Hart wrote: > > I strongly agree with all your points. The other submodule proposals are too > complex for me so I'm very happy to see a different solution which more > closely fits my design priorities. > Thanks David, > Comments

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

I’m concerned about the large source compatibility impact this change would have. Even if we claim that it’s only for Swift 4, migration would be difficult. Even if it were just a warning, that could be extremely noisy for large projects. What do you propose to mitigate that problem? I also

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

Thanks for your feedback. These are very fair concerns and point taken. There are other mechanisms we could use to achieve similar ends, I’ll work on some additional ideas. How do you view the overall goals/use cases? —Karim > On Mar 3, 2017, at 10:58 AM, Rien wrote:

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

I strongly agree with all your points. The other submodule proposals are too complex for me so I'm very happy to see a different solution which more closely fits my design priorities. Comments inline: > On 3 Mar 2017, at 16:24, Karim Nassar via swift-evolution >

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

I agree that “scope(set: file)” reads better. It does make it a little strange that “scope(set)" is also valid, though; it’s ambiguous whether it takes labeled or unlabeled arguments. Under this proposal, all of these are valid: scope var == scope(get, lexical) scope(set)

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 5:23 AM, Daniel Leping wrote: > > General impression is positive in case shortcuts (private, bulblic) still > remain for the most common use cases. The shorthand isn’t going anywhere. It is essential to making the system practical and familiar.

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 4:05 AM, Rien wrote: > > Just scanned it, but my first impression is: LOVE IT! > > IMO this is the way to go. > > Though some of the details will no doubt be improved. I will read it in more > depth coming WE. Awesome, thanks! I have already

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 3:19 AM, Adrian Zubarev via swift-evolution > wrote: > > (1) It seems odd to use scope as both an access control modifier alone and as > a function-like attribute. Perhaps something like access(set, scope) would be > better than scope(set). As

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

That’s what conditional conformances are made for in my opinion. The generics manifesto shows an example of equatable tuples iff every type is also equatable. That said, one probably should be able to extend a specific set of tuples to arithmetic operations if there is a need for that in your

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

I don’t like the file location based approach taken, see inline. Rien. > On 03 Mar 2017, at 16:24, Karim Nassar via swift-evolution > wrote: > > > I’ve read through the last couple of Swift (sub)Module proposals put forward, > and since my particular use-cases for

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

> On Mar 3, 2017, at 7:57 AM, Adrian Zubarev via swift-evolution > wrote: > > The question here is, how is a tuple different from a mathematical vector? I > wasn’t referring to vector concepts from other languages, but used the > keyword vector to indicate a

Re: [swift-evolution] [Review] SE-0156: Class and Subtype existentials

What is your evaluation of the proposal? +1 Is the problem being addressed significant enough to warrant a change to Swift? Yes Does this proposal fit well with the feel and direction of Swift? Yes How much effort did you put into your review? A glance, a quick reading, or an

[swift-evolution] Yet Another Take on Swift Sub-modules

I’ve read through the last couple of Swift (sub)Module proposals put forward, and since my particular use-cases for a sub-module solution seemed to be under-served by them, I’ve decided to write up my thoughts on the matter to prompt discussion. Perhaps my use-cases are outliers, and my

Re: [swift-evolution] [Review] SE-0156: Class and Subtype existentials

And what if we ever decide that restricting protocols to structs or enums should be allowed as well? AnyValue (_might_ happen with value sub typing)? Or maybe there are secret plans to add new reference types to Swift? Classes aren’t the only reference types in Swift, functions are also

Re: [swift-evolution] [Review] SE-0156: Class and Subtype existentials

Using ": class" always felt wrong for me — but only because of the convention that type names should start uppercase: What is wrong with "Class" instead of "AnyObject"? Object is a very broad term, and it isn't that uncommon to use it for all kinds of entities (not only reference types). And

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

The question here is, how is a tuple different from a mathematical vector? I wasn’t referring to vector concepts from other languages, but used the keyword vector to indicate a shortcut that provides a fixed or an arbitrary length such as …T would do in variadic generics context. A shortcut

Re: [swift-evolution] [Discussion] What is the future of tuples in Swift?

> I think that tuples should remain what they are now. Static-length vectors > should be types on their own and interact with tuples, with structs and with > Array<…> in the same way. > I strongly agree: Fixed-size vectors are a well known and simple concept that shouldn't be conflated with

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

(1) It seems odd to use scope as both an access control modifier alone and as a function-like attribute. Perhaps something like access(set, scope) would be better than scope(set). As it is, we’re conflating scope with meaning visibility and lexical scope—I found that very confusing. I like the