Re: [swift-evolution] Mark protocol methods with their protocol

[Maximilian Hünenberger via swift-evolution]

> Am 23.09.2016 um 12:47 schrieb Vladimir.S :
> 
>> On 23.09.2016 11:05, Maximilian Hünenberger wrote:
>> I'd also say that one or two keywords are superior than the protocol naming
>> approach in terms of implementation simplicity (for the core team).
>> 
>> My suggestions:
>> 
>> Either "conform" or "implement" should be a required keyword for all
>> properties/functions which implement a protocol (also in protocol extensions)
>> 
> 
>> "override" should be used if a default implementation or a member of a
>> superclass is overridden.
> 
> Maximilian, again, you *do not know* if the conformed protocol, that has no 
> default implementations *at the moment of your code writing* will or will not 
> have default implementations at the *moment of compilation*.
> Consider this scenario:
> 
> Step 1. You got 3rd party source file for your project, and you don't 
> want/have no rights to change it, probably it is shared source used also in 
> other projects, that code contains:
> 
> protocol A { func foo() }
> 
> class B : A {
>conform func foo() {...}
> }
> 
> all is OK with this code, no default implementation, B.foo marked with 
> `conform`.
> 
> Step 2. In your project in some of your files you decided to add default 
> implementation of protocol A:
> 
> extension A {
>implement func foo() {...}
> }
> 
> Now, your project will not compile - B.foo() must me marked with 'override' 
> as protocol `A` has default implementation of foo().
> If you change `conform` to `override` in 3rd party source file, it will not 
> compile in some other project where no default implementation defined for `A` 
> protocol.
> 
> That is *why* I believe the `override` as requirement as marker for protocol 
> implementation method/prop is the best solution. See, in case `override` will 
> be required, the initial source file will be like this:
> 
> protocol A { func foo() }
> 
> class B : A {
>override func foo() {...} // implementation
> }
> 
> and it will compile ok : if A has default implementation and if A has no 
> default implementation.
> 
> So, after you added default implementation in your project - no changes 
> should be made to that 3rd party source file.
> 
> 

In case of my suggestion this is an easy fix: `override` is not required if it 
overrides a member of an extension in another module.

My basic idea is to distinguish between implementation and (true) overriding 
(of other members. Do you agree?

Consider this:

protocol A1 {
func foo()
}

extension A1 {
implement func foo() {}
}

protocol A2: A1 {
override func foo() {}
}

In this case you know that `foo` in extension A1 does not override any other 
method.

Best regards
Maximilian

>> 
>> If you are overriding a default implementation of a protocol "conform" /
>> "implement" is also required.
>> 
>> // Retroactive conformance (old behavior) but only in extensions
>> extension Foo: @retroactive Baz {
>>// only some members of Baz are implemented here (they need the keywords)
>>// the other members outside the extension don't need any additional
>> keywords
>>// note: you can use "@retroactive" and "conform" in conjunction
>> }
>> 
>> 
>> *Future directions:*
>> "conform(ProtocolName)" / "override(ProtocolName)" can be used to 
>> disambiguate.
>> 
>> // reducing boilerplate
>> extension Foo: conform Bar {
>>// These declarations can only implement Bar and don't need the
>> "conform" keyword
>> }
>> 
>> *Final question:*
>> Should we also require a marker for implemented protocol members in the
>> interface?:
>> 
>> protocol Foo {
>>defaulted func foo()
>> }
>> extension Foo {
>>implement func foo()
>> }
>> 
>> 
>> Best regards
>> Maximilian

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Propagating Optionals

[Brent Royal-Gordon via swift-evolution]

On Sep 25, 2016, at 4:19 PM, Trans via swift-evolution  wrote:Basically "john.residence.numberOfRooms" is a completely wasted_expression_ -- it's meaningless.Not true; it's an attempt to access the `numberOfRooms` property on `Optional`. That property doesn't exist, but it could be added using an extension.(And `Optional` does have several members—most notably `map`, `flatMap`, and `unsafelyUnwrapped`.)-- Brent Royal-GordonArchitechies___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Mark UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public

[Dave Abrahams via swift-evolution]

on Sun Sep 25 2016, Chris Lattner  wrote:

> +1, assuming Dave Abrahams agrees.
>
> -Chris

Now that our comments have been addressed, I'm all for merging it.

>> On Sep 23, 2016, at 6:02 AM, Robert Widmann via swift-evolution 
>>  wrote:
>> 
>> +1.  This is a bug fix in my mind, evolution is merely a formality.
>> 
>> Ship it
>> 
>> ~Robert Widmann
>> 
>> 2016/09/22 18:59、Eli Perkins via swift-evolution
>> > のメッ
>> セージ:
>> 
>>> Hey all!
>>> 
>>> I picked up SR-2627 (https://bugs.swift.org/browse/SR-2627
>>> ) from the Swift JIRA
>>> project. The ticket states:
>>> 
>>> > UnicodeScalar.utf16 does not have access modifier and therefore
>>> is internal but should be public, as well as
>>> UnicodeScalar.UTF16View.
>>> 
>>> The ticket is written in a way that makes it seem as though this
>>> change would match the behavior of APIs such as the UTF accessors
>>> on `String`.
>>> 
>>> Additionally, `UnicodeScalar.utf16` and `Unicodescalar.UTF16View`
>>> seem to be created in `UnicodeScalar.swift`, but not used
>>> elsewhere, indicating that these properties were intended to be
>>> exposed to developers as part of the stdlib.
>>> 
>>> After submitting a pull request to implement this
>>> (https://github.com/apple/swift/pull/4929
>>> , Maxim Moiseev and
>>> Michael Gottesman mentioned that since this does modify the public
>>> API, a proposal should go through swift-evolution to address this.
>>> 
>>> I wanted to kick off the discussion here and get feedback from the mailing 
>>> list.
>>> 
>>> Looking forward to chatting about this!
>>> Eli Perkins
>>> ___
>>> 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
>

-- 
-Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Propagating Optionals

[William Sumner via swift-evolution]

> On Sep 25, 2016, at 2:19 PM, Trans via swift-evolution 
>  wrote:
> 
> As I've been learning Swift recently, one aspect of the language
> jumped out at me with a "code smell". Namely, the way Optionals are
> handled. For starters, just consider how long this chapter is:
> https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html
> That's pretty beefy for something on the surface is pretty simple.
> 
> More concretely, consider the example given:
> 
>   class Person {
>   var residence: Residence?
>   }
> 
>   class Residence {
>   var numberOfRooms = 1
>   }
> 
>   let john = Person()
> 
>   let roomCount = john.residence.numberOfRooms
> 
>   // error: value of optional type 'Residence?' not unwrapped; did
> you mean to use '!' or '?'?
> 
> As general rule of thumb, whenever I get an error and the system tells
> me what I probably meant, that is a pretty good sign the system isn't
> doing all it can for me and making me jump through an unnecessary
> hoop.
> 
> Basically "john.residence.numberOfRooms" is a completely wasted
> expression -- it's meaningless. You have to put a `?` or `!` in there
> to get anything useful. I can't see any good reason for that.
> "john.residence.numberOfRooms" could just behave one way or the other,
> either as if the `?` were there, or the `!`. And of the two, the
> obvious choice is `?` because... I already told the program it the was
> optional in "var residence: Residence?".  I said it was optional, and
> yep I meant that. (Reminds me of the old retort "did I stutter?")
> Thus, if I try to assign it to something else it too should be
> optional. If I want it to be otherwise I'd add the `!`.
> 
> Making this change would just simplify a whole mess of code and about
> half that chapter would all but vanish.

You have to be explicit about how to handle nullability because you’re 
attempting to access the property of an optional property.

> In addition, seeing that `!` acts a short-circuit to error, it would
> be nice to have something equivalent for fallback value. We can't use
> `??` b/c it doesn't chain, though maybe it could be made to? And I'd
> rather not reuse `?.` here  (for reasons I can explain later). Maybe
> `:` is a good choice? In any case, exact syntax aside,
> 
>   let homelessShelter = Residence()
>   let roomCount = john.residence:homelessShelter.numberOfRooms
> 
> Now, roomCount will not be optional, because there is a guaranteed value.
> 
> I think simplifying Optionals this way would be a good fit for Swift,
> making this part of the language a whole lot cleaner and clearer.


You can accomplish this using parenthesis:

let roomCount = (john.residence ?? homelessShelter).numberOfRooms

Preston

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Propagating Optionals

[Trans via swift-evolution]

As I've been learning Swift recently, one aspect of the language
jumped out at me with a "code smell". Namely, the way Optionals are
handled. For starters, just consider how long this chapter is:
https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/OptionalChaining.html
That's pretty beefy for something on the surface is pretty simple.

More concretely, consider the example given:

class Person {
var residence: Residence?
}

class Residence {
var numberOfRooms = 1
}

let john = Person()

let roomCount = john.residence.numberOfRooms

// error: value of optional type 'Residence?' not unwrapped; did
you mean to use '!' or '?'?

As general rule of thumb, whenever I get an error and the system tells
me what I probably meant, that is a pretty good sign the system isn't
doing all it can for me and making me jump through an unnecessary
hoop.

Basically "john.residence.numberOfRooms" is a completely wasted
expression -- it's meaningless. You have to put a `?` or `!` in there
to get anything useful. I can't see any good reason for that.
"john.residence.numberOfRooms" could just behave one way or the other,
either as if the `?` were there, or the `!`. And of the two, the
obvious choice is `?` because... I already told the program it the was
optional in "var residence: Residence?".  I said it was optional, and
yep I meant that. (Reminds me of the old retort "did I stutter?")
Thus, if I try to assign it to something else it too should be
optional. If I want it to be otherwise I'd add the `!`.

Making this change would just simplify a whole mess of code and about
half that chapter would all but vanish.

In addition, seeing that `!` acts a short-circuit to error, it would
be nice to have something equivalent for fallback value. We can't use
`??` b/c it doesn't chain, though maybe it could be made to? And I'd
rather not reuse `?.` here  (for reasons I can explain later). Maybe
`:` is a good choice? In any case, exact syntax aside,

let homelessShelter = Residence()
let roomCount = john.residence:homelessShelter.numberOfRooms

Now, roomCount will not be optional, because there is a guaranteed value.

I think simplifying Optionals this way would be a good fit for Swift,
making this part of the language a whole lot cleaner and clearer.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Mark UnicodeScalar.utf16 and UnicodeScalar.UTF16View as public

[Chris Lattner via swift-evolution]

+1, assuming Dave Abrahams agrees.

-Chris

> On Sep 23, 2016, at 6:02 AM, Robert Widmann via swift-evolution 
>  wrote:
> 
> +1.  This is a bug fix in my mind, evolution is merely a formality.
> 
> Ship it
> 
> ~Robert Widmann
> 
> 2016/09/22 18:59、Eli Perkins via swift-evolution  > のメッセージ:
> 
>> Hey all!
>> 
>> I picked up SR-2627 (https://bugs.swift.org/browse/SR-2627 
>> ) from the Swift JIRA project. The 
>> ticket states:
>> 
>> > UnicodeScalar.utf16 does not have access modifier and therefore is 
>> > internal but should be public, as well as UnicodeScalar.UTF16View.
>> 
>> The ticket is written in a way that makes it seem as though this change 
>> would match the behavior of APIs such as the UTF accessors on `String`.
>> 
>> Additionally, `UnicodeScalar.utf16` and `Unicodescalar.UTF16View` seem to be 
>> created in `UnicodeScalar.swift`, but not used elsewhere, indicating that 
>> these properties were intended to be exposed to developers as part of the 
>> stdlib.
>> 
>> After submitting a pull request to implement this 
>> (https://github.com/apple/swift/pull/4929 
>> , Maxim Moiseev and Michael 
>> Gottesman mentioned that since this does modify the public API, a proposal 
>> should go through swift-evolution to address this.
>> 
>> I wanted to kick off the discussion here and get feedback from the mailing 
>> list.
>> 
>> Looking forward to chatting about this!
>> Eli Perkins
>> ___
>> 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

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

[Karl via swift-evolution]

> On 25 Sep 2016, at 21:45, Drew Crawford  wrote:
> 
>> I think this is already part of the Generics Manifesto: 
>> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md 
>> 
> So is this proposal.  The proposal's "Motivation" is lifted from the 
> Arbitrary Requirements in Protocols section: 
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#arbitrary-requirements-in-protocols-
>  
> 

Sorry, what I meant to say is that: I think it would count as its own proposal 
(just because it has its own little section).

Although you’re right; the proposal includes concrete same-type constraints for 
sub-protocols (e.g. IntSequence) but we don’t have the same ability when 
extending existing protocols.
Maybe it would have been better to do the proposals the other way around.

- Karl___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

[Drew Crawford via swift-evolution]

I think this is already part of the Generics Manifesto: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

So is this proposal.  The proposal's "Motivation" is lifted from the Arbitrary 
Requirements in Protocols section: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#arbitrary-requirements-in-protocols-


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0142: Permit where clauses to constrain associated types

[Karl via swift-evolution]

> On 24 Sep 2016, at 21:58, Drew Crawford via swift-evolution 
>  wrote:
> 
> This is the #1 Swift feature I have wanted for the past 2 years.
> 
> One thing I would like to see (perhaps out of scope for this proposal) is the 
> natural extension for generic parameters:
> 
> struct Box {
> var t: T
> }
> 
> extension Box where T == Int { //error: Same-type requirement makes generic 
> parameter T non-generic
> }
> 
> There is a great deal of overlap between associated types and generic 
> parameters, and it seems to me that it would be favorable to allow `==` with 
> both generic parameter operands and associatedtype operands for consistency.
> 
> Drew
> 


I think this is already part of the Generics Manifesto: 
https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

> Concrete same-type requirements
> 
> Currently, a constrained extension cannot use a same-type constraint to make 
> a type parameter equivalent to a concrete type. For example:
> 
> extension Array where Element == String {
>   func makeSentence() -> String {
> // uppercase first string, concatenate with spaces, add a period, whatever
>   }
> }
> This is a highly-requested feature that fits into the existing syntax and 
> semantics. Note that one could imagine introducing new syntax, e.g., 
> extending Array, which gets into new-feature territory: see the 
> section on "Parameterized extensions".
> 

- Karl
> On September 23, 2016 at 6:51:51 PM, Douglas Gregor (dgre...@apple.com 
> ) wrote:
> 
>> Hello Swift community,
>> 
>> The review of SE-0142: "Permit where clauses to constrain associated types" 
>> begins now and runs through September 30, 2016. The proposal is available 
>> here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.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. When replying, please try to keep the proposal link at the top of 
>> the message:
>> 
>> Proposal link:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md
>>  
>> 
>> Reply text
>> 
>> Other replies
>>  
>> 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 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,
>> 
>> -Doug Gregor
>> 
>> Review Manager
>> 
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org 
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce 
>> 
> ___
> 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

Re: [swift-evolution] Source-breaking proposals?

[Karl via swift-evolution]

> On 25 Sep 2016, at 18:38, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Do I miss something, or proposals with source-breaking changes still can't be 
> submitted?
> When will corresponsing guidelines be out? Are there any plans on that matter?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

I believe the situation is that we’re going to support Swift 3 syntax with a 
compiler flag, which frees us to make source-breaking changes for Swift 4. 

AFAIK, how we support this in the compiler isn’t determined yet.

That’s what I take from Ted’s email: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025587.html

- Karl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Source-breaking proposals?

[Anton Zhilin via swift-evolution]

Do I miss something, or proposals with source-breaking changes still can't
be submitted?
When will corresponsing guidelines be out? Are there any plans on that
matter?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0141: Availability by Swift version

[T.J. Usiyan via swift-evolution]

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
If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
I think that holds up well.
How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
A quick read of the proposal.

On Fri, Sep 23, 2016 at 7:38 PM, Douglas Gregor  wrote:
>
> Hello Swift community,
>
> The review of SE-0141 "Availability by Swift version" begins now and runs
through September 28, 2016. The proposal is available here:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.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. When replying, please try to keep the proposal link at the
top of the message:
>
> Proposal link:
>
>
https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.md
>
> Reply text
>
> Other replies
>
> 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 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,
>
> -Doug Gregor
>
> Review Manager
>
>
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

[T.J. Usiyan via swift-evolution]

What is your evaluation of the proposal?
+1
Is the problem being addressed significant enough to warrant a change to
Swift?
Yes. A thousand times yes.
Does this proposal fit well with the feel and direction of Swift?
Yes.
If you have used other languages or libraries with a similar feature, how
do you feel that this proposal compares to those?
It compares well. Same type requirements for generic parameters are
sorely missed though.
How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
I've followed the discussion closely and given input a couple times.

More information about the Swift evolution process is available at

On Sun, Sep 25, 2016 at 6:39 AM, Dave Abrahams via swift-evolution <
swift-evolution@swift.org> wrote:

>
> on Fri Sep 23 2016, Douglas Gregor  wrote:
>
> > What is your evaluation of the proposal?
>
> It's ought to be obvious, but +1; when can I have it?
>
> > Is the problem being addressed significant enough to warrant a change
> > to Swift?
>
> Indeed.
>
> > Does this proposal fit well with the feel and direction of Swift?
>
> Yes.
>
> > If you have used other languages or libraries with a similar feature,
> > how do you feel that this proposal compares to those?
>
> I haven't, except maybe Haskell.
>
> > How much effort did you put into your review? A glance, a quick
> > reading, or an in-depth study?
>
> All that and more.
>
> Cheers,
> --
> -Dave
>
> ___
> 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

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

[Dave Abrahams via swift-evolution]

on Fri Sep 23 2016, Douglas Gregor  wrote:

> What is your evaluation of the proposal?

It's ought to be obvious, but +1; when can I have it?

> Is the problem being addressed significant enough to warrant a change
> to Swift?

Indeed.

> Does this proposal fit well with the feel and direction of Swift?  

Yes.

> If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?  

I haven't, except maybe Haskell.

> How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?  

All that and more.

Cheers,
-- 
-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

[John Holdsworth via swift-evolution]

> On 25 Sep 2016, at 04:07, Michael Gottesman  wrote:
> 
>> init(imageProducer:ImageProducer) {
>> withExtendedLifetime(CanvasBase()) {
>> super.init(javaObject: $0.javaObject)
>> }
>> image = createImage(imageProducer)
>> }
>> 
>> ..but the compiler was having none of it.
> 
> What was the error? I am assuming that super.init was not in the same 
> function?

Sorry, I should have included that in the email. The error was:

error: initializer chaining ('super.init') cannot be nested in another 
expression

Is it possible to build in an exception for withExtendedLifetime?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

[Dennis Lysenko via swift-evolution]

Oops, completely missed about 57 messages in the meat of this discussion,
so apologies if what I said was already suggested.

On Sun, Sep 25, 2016 at 4:35 AM Dennis Lysenko 
wrote:

> Could take a page out of Kotlin's book:
>
> x.let { foo(it) } // default argument name that isn't $0
>
> IMO, this syntax looks better as a one liner than "if x? { foo(x) }".
>
> The edge case here, with foo and bar being optional-returning functions,
> becomes:
> (foo(42), bar(43)).let { x, y in foo(x, y) } // default argument "it" here
> is a tuple so you can't pass it directly to the function, therefore you
> have to name x and y explicitly
>
> In which case it should be abundantly clear to the reader that there is NO
> short-circuiting and both foo and bar are evaluated as a tuple before the
> "let" function is called on that tuple.
>
> On Sun, Sep 25, 2016 at 3:24 AM Justin Jia via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Sep 24, 2016, at 7:31 PM, Dany St-Amant  wrote:
>>
>> Reading some old threads...
>>
>> Le 16 août 2016 à 15:12, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> a écrit :
>>
>> On Tue, Aug 16, 2016 at 12:14 PM, Justin Jia <
>> justin.jia.develo...@gmail.com> wrote:
>>
>>> I was trying to argue with reason. You kept stating your *opinion*. You
>>> still didn't explain *why*. For example, why "if statements can and
>>> function calls can't" and why "this severely violates user expectations"?
>>>
>>
>> These were not meant as expressions of opinion. Currently, in Swift, `if`
>> statements can short circuit and function calls cannot. Your proposal would
>> introduce short-circuiting where currently there can be none, and thus it
>> would severely violate user expectations.
>>
>>
>> Function calls can currently be short-circuited... if there's try and
>> throw involved.
>>
>> let z = try g(f1(a), f2(b), f3(c)) // Must be within do {} catch {}
>>
>> Assuming f1(), f2(), f3() can all throws, f2() is only called if f1() did
>> not throw, and f3() if neither f1() nor f2() threw. The behavior is/seems
>> to be: Pure left to right execution order regardless of throwing ability.
>>
>> If g() doesn't throw, the above (with exact same behavior) can be written
>> more verbosely and explicitly as:
>>
>> let y = g(try f1(a), try f2(b), try f3(c)) // Must be within do {} catch
>> {}
>>
>> Yet another way to do the call is:
>>
>> let x = try? g(f1(a), f2(b), f3(c)) // z is nil on throws
>>
>> So implementing something like what Justin is asking should fit within
>> Swift, as long as it follows the try short-circuit logic. However, the use
>> of a trailing question-mark to provide this functionality is not explicit
>> enough to my taste (and to my weakening eyesight). Could we reuse let but
>> with a question-mark? Or maybe guard.
>>
>>
>> Good point! Edge cases always exist.
>>
>> let z = g(let? f1(a), let? f2(b), let? f3(c))
>> // z is nil on fX() == nil, otherwise Optional(g()) just like try?
>> wrapping
>> // left to right short-circuit à la let z = try?
>>
>>
>> This sounds like a good idea. Moving the keyword to the front is more
>> explicit. But `let? f1(a)` seems a little bit weird to me.
>>
>> What about `let x = if? foo(x, y)` But… should we introduce `if!` as well?
>>
>> ```
>> func foo(x: Any, y: Any) { … }
>>
>> let x: Any? = nil
>> let y: Any? = nil
>> if? foo(x, y) // If x and y both can be unwrapped, execute foo().
>> if? foo(x?, y?) // Or if we want to be a little bit more clear, specify
>> which argument could be optional
>> ```
>>
>> ```
>> if! foo(x, y) // Will crash if nil is found.
>> if! foo(x!, y!) // To be more clear
>> ```
>>
>> Backward compatibility:
>>
>> ```
>> foo(x!, y!) // warning: add if! before the function
>> ```
>>
>> Though, this may ask for also supporting something like:
>>
>> let x = g(let? try? f1(a), let? try? f2(b), let? try? f3(c))
>>
>> This allow selective discard of throws, instead of a discard all of a
>> plain 'let x = try? ...'
>>
>>
>> Yes.
>>
>> Dany
>>
>> ... snip ...
>>>
>>
> On Aug 16, 2016, at 1:16 AM, Xiaodi Wu  wrote:
>>
>> On Mon, Aug 15, 2016 at 12:07 PM, Xiaodi Wu 
>> wrote:
>>
>>> On Mon, Aug 15, 2016 at 11:43 AM, Justin Jia <
>>> justin.jia.develo...@gmail.com> wrote:
>>>
 I believe the core team has considered 99% of the ideas in the
 mailing list in the past, but it doesn’t mean we can’t discuss it, 
 right?

>>> .. snip ...
>>>

 Back to the original topic.

 I spent some time thinking and changed my mind again. I think
 solution 1 is most reasonable. It is consistent with if statements. 
 Instead
 of treating it as sugar for `if let`, we can treat it as sugar for 
 `guard`,
 which is much easy to understand and remember.

 -

 Below is the reason why I think 

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

[Dennis Lysenko via swift-evolution]

Could take a page out of Kotlin's book:

x.let { foo(it) } // default argument name that isn't $0

IMO, this syntax looks better as a one liner than "if x? { foo(x) }".

The edge case here, with foo and bar being optional-returning functions,
becomes:
(foo(42), bar(43)).let { x, y in foo(x, y) } // default argument "it" here
is a tuple so you can't pass it directly to the function, therefore you
have to name x and y explicitly

In which case it should be abundantly clear to the reader that there is NO
short-circuiting and both foo and bar are evaluated as a tuple before the
"let" function is called on that tuple.

On Sun, Sep 25, 2016 at 3:24 AM Justin Jia via swift-evolution <
swift-evolution@swift.org> wrote:

> On Sep 24, 2016, at 7:31 PM, Dany St-Amant  wrote:
>
> Reading some old threads...
>
> Le 16 août 2016 à 15:12, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> On Tue, Aug 16, 2016 at 12:14 PM, Justin Jia <
> justin.jia.develo...@gmail.com> wrote:
>
>> I was trying to argue with reason. You kept stating your *opinion*. You
>> still didn't explain *why*. For example, why "if statements can and
>> function calls can't" and why "this severely violates user expectations"?
>>
>
> These were not meant as expressions of opinion. Currently, in Swift, `if`
> statements can short circuit and function calls cannot. Your proposal would
> introduce short-circuiting where currently there can be none, and thus it
> would severely violate user expectations.
>
>
> Function calls can currently be short-circuited... if there's try and
> throw involved.
>
> let z = try g(f1(a), f2(b), f3(c)) // Must be within do {} catch {}
>
> Assuming f1(), f2(), f3() can all throws, f2() is only called if f1() did
> not throw, and f3() if neither f1() nor f2() threw. The behavior is/seems
> to be: Pure left to right execution order regardless of throwing ability.
>
> If g() doesn't throw, the above (with exact same behavior) can be written
> more verbosely and explicitly as:
>
> let y = g(try f1(a), try f2(b), try f3(c)) // Must be within do {} catch {}
>
> Yet another way to do the call is:
>
> let x = try? g(f1(a), f2(b), f3(c)) // z is nil on throws
>
> So implementing something like what Justin is asking should fit within
> Swift, as long as it follows the try short-circuit logic. However, the use
> of a trailing question-mark to provide this functionality is not explicit
> enough to my taste (and to my weakening eyesight). Could we reuse let but
> with a question-mark? Or maybe guard.
>
>
> Good point! Edge cases always exist.
>
> let z = g(let? f1(a), let? f2(b), let? f3(c))
> // z is nil on fX() == nil, otherwise Optional(g()) just like try? wrapping
> // left to right short-circuit à la let z = try?
>
>
> This sounds like a good idea. Moving the keyword to the front is more
> explicit. But `let? f1(a)` seems a little bit weird to me.
>
> What about `let x = if? foo(x, y)` But… should we introduce `if!` as well?
>
> ```
> func foo(x: Any, y: Any) { … }
>
> let x: Any? = nil
> let y: Any? = nil
> if? foo(x, y) // If x and y both can be unwrapped, execute foo().
> if? foo(x?, y?) // Or if we want to be a little bit more clear, specify
> which argument could be optional
> ```
>
> ```
> if! foo(x, y) // Will crash if nil is found.
> if! foo(x!, y!) // To be more clear
> ```
>
> Backward compatibility:
>
> ```
> foo(x!, y!) // warning: add if! before the function
> ```
>
> Though, this may ask for also supporting something like:
>
> let x = g(let? try? f1(a), let? try? f2(b), let? try? f3(c))
>
> This allow selective discard of throws, instead of a discard all of a
> plain 'let x = try? ...'
>
>
> Yes.
>
> Dany
>
> ... snip ...
>>
>
 On Aug 16, 2016, at 1:16 AM, Xiaodi Wu  wrote:
>
> On Mon, Aug 15, 2016 at 12:07 PM, Xiaodi Wu 
> wrote:
>
>> On Mon, Aug 15, 2016 at 11:43 AM, Justin Jia <
>> justin.jia.develo...@gmail.com> wrote:
>>
>>> I believe the core team has considered 99% of the ideas in the
>>> mailing list in the past, but it doesn’t mean we can’t discuss it, 
>>> right?
>>>
>> .. snip ...
>>
>>>
>>> Back to the original topic.
>>>
>>> I spent some time thinking and changed my mind again. I think
>>> solution 1 is most reasonable. It is consistent with if statements. 
>>> Instead
>>> of treating it as sugar for `if let`, we can treat it as sugar for 
>>> `guard`,
>>> which is much easy to understand and remember.
>>>
>>> -
>>>
>>> Below is the reason why I think this feature is important (quoted
>>> from another email).
>>>
>>> The problem with `if let` is you need to call the function inside {
>>> }.
>>>
>>> ```
>>> /* code 1 */
>>> if let x = x, let y = y {
>>> /* code 2, depends on x and y to be non-optional */
>>> let z = foo(x, y)
>>> if let z = z {
>>>