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

[Alex Johnson via swift-evolution]

I’d be fine losing the ability to pass methods as escaping closures.

I wouldn’t like losing the ability to pass methods as non-escaping closures, 
because I find this pattern pretty useful:

  class MyViewController {
   var records: [Record]
   var visibleRecords: [Record] { return records.filter(isVisible) }

func isVisible(_ record: Record) -> Bool {
// some logic here, maybe using other properties of `self`
}
  }

Alex Johnson
ajohn...@walmartlabs.com
ajohnson on Slack

From:  on behalf of Anton Zhilin 

Date: Saturday, March 4, 2017 at 1:45 AM
To: "swift-evolution@swift.org" 
Cc: Alex Johnson 
Subject: Re: [swift-evolution] Should explicit `self.` be required when 
providing method as closure?


I disagree with dropping function references in general, but I do agree with 
limiting partially applied method references.

In @escaping arguments, adding self. won’t add enough evidence that it actually 
creates a closure with capture.
Even in non-escaping context, I find plain method references odd:

2017-03-04 10:09 GMT+03:00 David Hart via swift-evolution 
>:
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.
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alex Johnson via swift-evolution]

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 of `self`. From a memory management 
perspective, this code is equivalent to:

self.relatedObject = RelatedObject(callback: { self.relatedObjectDidFinish 
})

In the second example, an explicit `self.` is required. It’s my understanding 
that this is to highlight that the closure keeps a strong reference to `self`. 
But, when passing a method, there is no such requirement, which makes it easier 
to accidentally create a retain cycle.

This made me wonder if an explicit `self.` should be required when passing a 
method as an escaping closure. And whether that would help in the same way that 
the explicit `self.` *inside* the closure is intended to.

If it were required, the code in the first example would be:

self.relatedObject = RelatedObject(callback: self.relatedObjectDidFinish)

What do you think?

Alex Johnson
ajohn...@walmartlabs.com
ajohnson on Slack
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

[Alex Johnson via swift-evolution]

(this is mostly a repost of a message I sent to the "[draft]" thread for
this proposal, with some light editing to better match terminology in the
proposal)

*What is your evaluation of the proposal?*

I like this proposal. I think it will bring some much-needed ease-of-use.

I have reservations about the "..." placeholder for the memberwise
initialization parameters, though. I know this was suggested by
Chris Lattner, so I'm inclined to defer to his judgement. But, here are my
thoughts:

First, it's very close to the varags syntax (e.g. "Int...") which can also
appear in initializer parameter lists.

Second, and I think more important, I'm not sure that it's all that *useful*.
It's presence isn't necessary for triggering memberwise initialization
synthesis; that is already done by the "memberwise" keyword.

The primary example given in the proposal is:

memberwise init(anInt: Int, anotherInt: Int, ...) {

  /* code using anInt and anotherInt */

}


That is, it's used to indicate where the synthesized parameters appear in
the parameter list if there are also custom (non-memberwise) parameters.

My question is, *could the memberwise initialization parameters always be
last?* That would eliminate the need for the placeholder.

I don't think I've seen a compelling case for embedding the "..." *within*
a list of custom arguments, like:

memberwise init(anInt: Int, ..., anotherInt: Int) {
  /* code using anInt and anotherInt */
}


It's been mentioned several times in the discussion of this proposal that
this behavior is purely optional. If it turns out that there are rare cases
where placing the memberwise params in the middle is useful, authors can
use manual initialization.


On Wed, Jan 6, 2016 at 2:47 PM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> Hello Swift community,
>
> The review of "Flexible Memberwise Initialization" begins now and runs
> through January 10th. The proposal is available here:
>
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md
>
> Reviews are an important part of the Swift evolution process. All reviews
> should be sent to the swift-evolution mailing list at
>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> or, if you would like to keep your feedback private, directly to the
> review manager.
>
> What goes into a review?
>
> The goal of the review process is to improve the proposal under review
> through constructive criticism and, eventually, determine the direction of
> Swift. When writing your review, here are some questions you might want to
> answer in your review:
>
> * What is your evaluation of the proposal?
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
> * Does this proposal fit well with the feel and direction of Swift?
> * If you have you used other languages or libraries with a similar
> feature, how do you feel that this proposal compares to those?
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
> More information about the Swift evolution process is available at
>
> https://github.com/apple/swift-evolution/blob/master/process.md
>
> Thank you,
>
> -Chris
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 

*Alex Johnson | Engineering Lead*

*Quick Left, Inc. *
*Boulder **|* *Denver* *|* *Portland** |** San Francisco*

1 (844) QL-NERDS

@nonsensery


 
 
 


*What's it like to work with us? **TrainingPeaks, iTriage, and Ping
Identity share their stories in this short video** A Client's View
*.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0018 Flexible Memberwise Initialization

[Alex Johnson via swift-evolution]

Hi Matthew,

Thanks for the explanation.

Before getting into a deeper discussion, I'd like to try to enumerate the
reasons for adding the placeholder as I understand them:

   1. Add clarity by visually distinguishing memberwise initializers from
   normal initializers.
   2. Introduce a "synthesized parameters placeholder" syntax that might be
   useful in other places.
   3. Allow some control over where the synthesized memberwise parameters
   end up in the initializer signature.

Does that seem accurate?

~ Alex


On Wed, Jan 6, 2016 at 3:48 PM, Matthew Johnson <matt...@anandabits.com>
wrote:

>
> On Jan 6, 2016, at 5:26 PM, Alex Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> (this is mostly a repost of a message I sent to the "[draft]" thread for
> this proposal, with some light editing to better match terminology in the
> proposal)
>
> *What is your evaluation of the proposal?*
>
> I like this proposal. I think it will bring some much-needed ease-of-use.
>
> I have reservations about the "..." placeholder for the memberwise
> initialization parameters, though. I know this was suggested by
> Chris Lattner, so I'm inclined to defer to his judgement. But, here are my
> thoughts:
>
> First, it's very close to the varags syntax (e.g. "Int...") which can
> also appear in initializer parameter lists.
>
>
> Second, and I think more important, I'm not sure that it's all that
> *useful*. It's presence isn't necessary for triggering memberwise
> initialization synthesis; that is already done by the "memberwise" keyword.
>
> The primary example given in the proposal is:
>
> memberwise init(anInt: Int, anotherInt: Int, ...) {
>
>   /* code using anInt and anotherInt */
>
> }
>
>
> That is, it's used to indicate where the synthesized parameters appear in
> the parameter list if there are also custom (non-memberwise) parameters.
>
> My question is, *could the memberwise initialization parameters always be
> last?* That would eliminate the need for the placeholder.
>
> I don't think I've seen a compelling case for embedding the "..." *within*
> a list of custom arguments, like:
>
> memberwise init(anInt: Int, ..., anotherInt: Int) {
>   /* code using anInt and anotherInt */
> }
>
>
> It's been mentioned several times in the discussion of this proposal that
> this behavior is purely optional. If it turns out that there are rare cases
> where placing the memberwise params in the middle is useful, authors can
> use manual initialization.
>
>
> Hi Alex, thanks for your review.
>
> The initial draft of the proposal did exactly what you suggest - it did
> not include the placeholder and always placed the memberwise parameters
> last.  Personally, I believe the placeholder adds clarity and really liked
> the idea when Chris suggested it.
>
> Aside from personal preference, I like that this proposal introduces a
> “synthesized parameter placeholder” syntax.  Similar syntax will also be
> used in the parameter forwarding proposal mentioned in the future
> enhancements section of this proposal.
>
> I think the `…` works really well.  That said, I don’t mind if people wish
> to bikeshed on it.  If that discussion starts it is worth noting that one
> thing I like about the `…` is that it combines with an identifier cleanly.
> For example : `…memberwise`.
>
> Combining the placeholder with an identifier allows more than one
> placeholder to be used in the same parameter list.  For example, if you are
> forwarding memberwise parameters exposed by a super init you might also
> have `…super`.
>
> That said, I don’t want the review thread to get distracted with
> discussions around general parameter forwarding so please just consider
> this as a preview of how this syntax might scale to future applications.
> For now, lets keep this thread focused on the review of the current
> proposal.  :)
>
> Matthew
>
>
>
> On Wed, Jan 6, 2016 at 2:47 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello Swift community,
>>
>> The review of "Flexible Memberwise Initialization" begins now and runs
>> through January 10th. The proposal is available here:
>>
>>
>> https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md
>>
>> Reviews are an important part of the Swift evolution process. All reviews
>> should be sent to the swift-evolution mailing list at
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> or, if you would like to keep your feedback private, directly to the
>> rev

Re: [swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

[Alex Johnson via swift-evolution]

Escaping self with back-ticks is an intriguing workaround for this.
However, I think escaping keywords with back-ticks for anything other than
avoiding interop naming issues should be considered an antipattern.

Allowing "guard let self = self else { return }" makes a lot of sense to me.

On Wed, Jan 6, 2016 at 1:18 PM, Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:

> But “self” _is_ a reserved word, and that’s the whole reason that this
> proposal is necessary in the first place. If “self” were just a normal
> identifier, then “if let self = self” would work just as well as “if let
> foo = foo” and there would be nothing to discuss.
>
> The docs also say "The backticks are not considered part of the
> identifier; `x` and x have the same meaning." Thus `self` and self should
> have the same meaning.
>
>
> Well, `flurtzle` and flurtzle would have the same meaning, but `self` is
> an identifier whereas as self is a keyword, so they mean different things.
> That is precisely what the backticks are for.
>
> Assigning to `self` is the same as assigning to self, which intentionally
> isn't allowed.
>
>
> No, you’re creating a new identifier called “self” which shadows the old
> one.
>
> Consider this:
>
> let foo: Int? = 7
> if let foo = foo {
> print(foo + 1)
> }
>
> There are two identifiers named foo, one optional, one not. Both are
> declared with “let”, so neither can be assigned to. But the code works.
> Why? Because “let foo = foo” doesn’t assign to the outer variable; it
> creates a new one. If self were not a keyword, then it would work the same
> as “foo” above.
>
> Cheers,
>
> Paul
>
>
> On Jan 6, 2016, at 2:56 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Not exactly; backticks are for making an identifier out of something
> that's not normally an identifier. Most other reserved words are used in
> control flow & other declarations. Rarely do they actually represent
> identifiers/values that you can work with.
>
> The docs also say "The backticks are not considered part of the
> identifier; `x` and x have the same meaning." Thus `self` and self should
> have the same meaning. Assigning to `self` is the same as assigning to
> self, which intentionally isn't allowed. Backticks shouldn't allow you to
> circumvent that.
>
> Jacob
>
> On Wed, Jan 6, 2016 at 12:50 PM, Paul Cantrell  wrote:
>
>> Ummm … isn’t that _exactly_ what backticks are for? From the docs:
>>
>> To use a reserved word as an identifier, put a backtick (`) before
>> and after it.
>>
>>
>> On Jan 5, 2016, at 10:42 PM, Greg Parker via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I think it is a bug  :-)  That's not what backquotes are for. It ought to
>> be either supported without the backquotes or banned regardless of
>> backquotes.
>>
>> On Jan 5, 2016, at 8:34 PM, Jacob Bandes-Storch 
>> wrote:
>>
>> Yes, it seems to use the strong shadowing variable. (The compiler doesn't
>> complain about "self.foo", and "self?.foo" becomes invalid because self is
>> no longer optional.)
>>
>> If it weren't so useful, I'd call it a bug.
>>
>> On Tue, Jan 5, 2016 at 8:34 PM, Greg Parker  wrote:
>>
>>> Does further use of self after that actually use a strong shadowing
>>> variable? Or does it go back to the weak reference it already had as if the
>>> shadow were not there?
>>>
>>> On Jan 5, 2016, at 8:26 PM, Jacob Bandes-Storch via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Wow! I didn't know that worked. It's a bit surprising, and perhaps not
>>> intended. I think the proposal is still valid.
>>>
>>> On Tue, Jan 5, 2016 at 8:21 PM, Christopher Rogers <
>>> christorog...@gmail.com> wrote:
>>>
 You can shadow self with a guard like you wrote it if use the keyword
 escaping backquotes like so:

 guard let `self` = self else { return }
>>>
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 

*Alex Johnson | Engineering Lead*

*Quick Left, Inc. *
*Boulder **|* *Denver* *|* *Portland** |** San Francisco*

1 (844) QL-NERDS

@nonsensery


 
 
 


*What's it like to work with us? **TrainingPeaks, iTriage, and Ping
Identity share their stories in this short video** A 

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

[Alex Johnson via swift-evolution]

Hopefully this is still the right place to discuss this proposal (it's listed
as being in active review
, but I
don't see a separate [Review] thread).

I like this proposal. I think it will bring some much-needed ease-of-use.

I'm not sold on the "..." placeholder for the memberwise arguments, though.
I know this was suggested by Chris Lattner, so I'm tempted to defer to his
judgement. But here are my thoughts:

First, it's very close to the varags syntax (e.g. "Int...") which can also
appear in initializer argument lists.

Second, and I think more important, I'm not sure that it's all that *useful*.
Aside from being used to mark the initializer as having "memberwise"
semantics, which is already done by the "memberwise" keyword, the most
common example I've seen is code like this:

memberwise init(customArg: Int, ...) {
  /* use customArg */
}


That is, it's used to indicate where the synthesized arguments appear in
the argument list if there are also custom (non-memberwise) arguments.

My question is, *why not always put the memberwise arguments last?* That
would eliminate the need for the placeholder (aka "...").

I don't think I've seen a compelling case for embedding the "..." *within* a
list of custom arguments, like:

memberwise init(customArg1: Int, ..., customArg2: Int) {
  /* use customArg1 and customArg2 */
}


And it's been mentioned several times that this is purely additive. If
there *is* an obscure case where that is useful, the author can write use
manual initialization.


On Wed, Jan 6, 2016 at 6:48 AM, Thorsten Seitz via swift-evolution <
swift-evolution@swift.org> wrote:

> Ok, that makes sense.
>
> -Thorsten
>
> > Am 03.01.2016 um 00:24 schrieb Chris Lattner :
> >
> >
> >> On Jan 2, 2016, at 2:48 PM, Thorsten Seitz 
> wrote:
> >>
> >> One question just occurred to me: do we really need the keyword
> „memberwise“ anymore? Wouldn’t just using "init(…)“ be sufficient?
> >
> > It wouldn’t be necessary to make the parser work, but I think we’d want
> something to make it clear what was intended.  Otherwise, you could write:
> >
> >init(a : Int, …)
> >
> > when you meant:
> >init(a : Int …)
> >
> > and unfortunate things would happen.  The memberwise keyword also makes
> it much more clear to the reader what is going on.
> >
> > -Chris
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>



-- 

*Alex Johnson | Engineering Lead*

*Quick Left, Inc. *
*Boulder **|* *Denver* *|* *Portland** |** San Francisco*

1 (844) QL-NERDS

@nonsensery


 
 
 


*What's it like to work with us? **TrainingPeaks, iTriage, and Ping
Identity share their stories in this short video** A Client's View
*.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Thoughts on clarity of Double and Float type names?

[Alex Johnson via swift-evolution]

Hi all,

I'm curious how other members of the Swift community feel about the clarity
of the "Double" and "Float" type names. It seems incongruous that the
default type for integers is "Int", but the default type for floating point
numbers is not "Float".

What if the name "Float" were given to the intrinsic, 64-bit floating point
type? (And the existing "Float" and "Double" names were removed in favor of
"Float32" and "Float64"?)


*Discussion:*

I understand the origins of these names in single- and double-precision
IEEE floats. But this distinction feels like a holdover from C (and a
32-bit world), rather than a natural fit for Swift.

Here are some reasons to *keep Double and Float as they are* (numbered for
easy reference, but otherwise unordered):

   1. "Double" and "Float" are more natural for developers who are
   "familiar with C-like languages."
   2. A corollary: A 64-bit "Float" type could be confusing to those
   developers.
   3. Another corollary: Swift needs to interoperate with Objective C, and
   its "float" and "double" types.
   4. Renaming these types would open the door to bike-shedding every type
   name and keyword in the language.
   5. Changing the meaning of an existing type ("Float") would be a bit
   PITA for existing code (although an automated migration from "Float" to
   "Float32" and "Double" to "Float" should be possible).
   6. Renaming a fundamental type would take considerable effort.

Here are some reasons to *rename these types*:

   1. The default for a "float literal" in Swift is a 64-bit value. It
   would feel natural if that that value were of type "Float".
   2. There are size-specific names for 32-bit ("Float32") and 64-bit
   ("Float64") floating point types. For cases where a size-specific type is
   needed, a size-specific name like "Float32" probably makes the intention of
   the code more clear (compared to just "Float").
   3. Apple's Objective C APIs generally use aliased types like "CGFloat"
   rather than raw float or double types.
   4. There is precedent for "Float" types being 64-bit in other languages
   like Ruby, Python and Go (as long as the hardware supports it).
   5. What kind of a name for a type is "Double" anyways, amirite?

(that last one is a joke, BTW)

What do you think? Do you agree or disagree with any of my assessments? Are
there any pros or cons that I've missed? Is the level of effort so large
that it makes this change impractical? Is it a colossal waste of human
effort to even consider a change like this?

Thanks for your time and attention,
Alex Johnson (@nonsensery)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution