Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

> > One could workaround the problem and use final, but what if the class > meant to be subtypeable? Self simply does not work in this scenario. > > > It works exactly as it should in this scenario. If A isn't final, then by > definition it's impossible for A to make a copy of type Self. I

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

On Sat, Jan 7, 2017 at 4:00 PM, Braeden Profile via swift-evolution < swift-evolution@swift.org> wrote: > * One could workaround the problem and use final, but what if the class > ** meant to be subtypeable? Self simply does not work in this scenario. > * > It works exactly as it should in this

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

> > Of course, I would love being able to use an initializer setup, but there are > serious bugs in the implementation. > > protocol Clonable > { > init(other: Self) > } > > extension Clonable > { > func clone() -> Self > { return type(of: self).init(other: self) } >

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

On Sat, Jan 7, 2017 at 5:33 PM, Braeden Profile wrote: > >> Of course, I would love being able to use an initializer setup, but there >> are serious bugs in the implementation. >> >> protocol Clonable >> { >> init(other: Self) >> } >> >> extension Clonable >> { >>

[swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

FWIW, I searched the previous proposals for any kind of mention of tuple and found nothing so forgive me if this has been discussed before. Swift currently has 5 ways to represent multi-values. Classes, structs, arrays, dictionaries, and tuples. Of these, classes are well established and

[swift-evolution] [Proposal draft] Use obtain let instead if let construction

Hi all, Here’s a draft proposal to change if let construction for obtain let. Proposal is at: https://github.com/carlosypunto/swift-evolution/blob/obtain-let-instead-if-let/proposals/-Use-obtain-let-instead-if-let-constructions.md

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

> On Jan 7, 2017, at 18:17, Freak Show via swift-evolution > wrote: > > It should also be noted that I am not a compiler or VM writer and I don't > give a fig how the language does things at the implementation level and this > is primarily a conceptual/syntactic

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1 from me, I think that it makes perfect sense the way it is. More specifically, I read `if let safe = optional` as "if optional can be unwrapped into safe, then ..." I think `obtain let` is more confusing, as it's not clear that it's a conditional from that keyword. Plus to me, "obtain" seems

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

Based on your examples I think you were thinking about the "guard" keyword, instead of "if"? `If let foo = bar else` is not a valid construction. `if let foo = bar { } else {}` may have been what you meant, but in this case it is clear that this is just like a regular if, combined with unwrapping

Re: [swift-evolution] Enhanced Existentials

Sent from my iPhone > On Jan 6, 2017, at 11:04 PM, Russ Bishop wrote: > > >> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution >> wrote: >> >> >>> >>> Would love to see this come forward into discussion. >> >> Yeah. I'm less

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1. Your proposal seems to confuse something we already have in the language to handle unwrapping and guarding, to only proceed if the item is non-null: Guard. We already have a keyword and behaviour that you specify in the “guard” behaviour. Additionally, changing “guard” to be “obtain”

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

Hi Javier, Maybe I’m not explained correctly in email. The change is not a "guard let” replacement, instead it is a “if let” replacement. Best, Carlos > On 08 Jan 2017, at 05:45, Javier Soto wrote: > > Based on your examples I think you were thinking about the "guard"

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

Hi Rod, Maybe I’m not explain correctly in email. The change is not a "guard let” replacement, instead it is a “if let” replacement. Best, Carlos > On 08 Jan 2017, at 07:22, Rod Brown wrote: > > -1. > > Your proposal seems to confuse something we already have in

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

> On Jan 7, 2017, at 19:34, Freak Show wrote: > > I think you're missing the forrest for the trees here.' > > Let me ask this: if you remove tuples from the language - what have you lost > - really? You can still say everything you could before. A really convenient

Re: [swift-evolution] Cancelable named defer statements

A closure assigned to a variable is already a named handler… Make it optional and it’s now a cancelable named handler… Put it in a defer block and you have exactly what you want, a cancelable named defer handler… func doSomething(input: String) -> String? { // Create a cancelable named defer

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

I like this idea, however, if I understand the proposal correctly, I think that the naming would make more sense the other way around. `Self` is, at least in my head, tied directly and statically to the enclosing type, where as `Current` sounds more dynamic, and could change from

Re: [swift-evolution] Cancelable named defer statements

-1. Much of the utility of `defer` is that it's guaranteed to execute. As you demonstrate, it's possible to capture a flag and choose not to do something within the defer block itself. We don't need sugar for that. On Sat, Jan 7, 2017 at 12:20 PM, Rien via swift-evolution <

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

On Sat, Jan 7, 2017 at 11:34 AM, Xiaodi Wu wrote: > `Self` _always_ refers to the dynamic type of `self`. It just happens to > be that in the case of structs the dynamic type is the same as the static > type. The idea of having a shorthand for the containing type (spelled

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

`Self` _always_ refers to the dynamic type of `self`. It just happens to be that in the case of structs the dynamic type is the same as the static type. The idea of having a shorthand for the containing type (spelled #Self or StaticSelf) was discussed during consideration of SE-0068. The accepted

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

True, but there are a few edge cases where Self simply does not work. On classes the return type has the contract to return self. Even if we get SE–0068, will Self work in generic context like showed in OP with Current? #1 Using value semantics on classes means that the returned instance is a

Re: [swift-evolution] Cancelable named defer statements

Any cancelable defer addition we could come up with will need a flag/state to indicate so, which won't be that much different from what you wrote. Having said that, for your example may I suggest this approach instead: func openFile(kind: String) -> UnsafeMutablePointer? { var file =

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

> On 5 Jan 2017, at 02:25, Jay Abbott via swift-evolution > wrote: > > When you have a function with a closure and then another optional default = > nil closure at the end, like this: > > open static func animate(identifier: String, >

[swift-evolution] Cancelable named defer statements

Is there any interest in a proposal to introduce a named defer statement that can be cancelled? Lately I find myself writing this kind of code: func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r") var closeFile = true defer { if

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

I have no problem with the syntax proposed in SE-0068. The rationale briefly mentions that dynamic Self will be used anywhere inside the class body. I think that the possibilities that open with this decision should be mentioned in the proposal. We can say that non-final classes, apart from that

Re: [swift-evolution] Enhanced Existentials

> On 7 Jan 2017, at 08:04, Russ Bishop via swift-evolution > wrote: > > >> On Jan 4, 2017, at 8:48 PM, Douglas Gregor via swift-evolution >> wrote: >> >> >>> >>> Would love to see this come forward into discussion. >> >> Yeah. I'm

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

On Sat, Jan 7, 2017 at 12:02 PM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > True, but there are a few edge cases where Self simply does not work. > >1. On classes the return type has the contract to return self. >2. Even if we get SE–0068, will Self work in generic context

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1. This proposal is, in fact, cosmetic and has no impact on matters related to the ABI. Moreover it is a breaking change that would require migration of a lot of existing code without significant justification. A verb in this position is far more confusing than a logical connective.

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

I just realized my mistake in the example, I've corrected it > On 08 Jan 2017, at 07:46, Carlos García wrote: > > Hi Javier, > > Maybe I’m not explained correctly in email. The change is not a "guard let” > replacement, instead it is a “if let” replacement. > > Best,

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

I just realized my mistake in the example, I've corrected it > On 08 Jan 2017, at 07:45, Carlos García wrote: > > Hi Rod, > > Maybe I’m not explain correctly in email. The change is not a "guard let” > replacement, instead it is a “if let” replacement. > > Best, >

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

-1, ‘obtain' obfuscates the meaning of the “if” statement. Since it would (conceptually) introduce a new statement that is very similar to the ‘if’ statement and ‘guard’ statement it would probably cause even more confusion. Regards, Rien Site: http://balancingrock.nl Blog:

Re: [swift-evolution] Consolidate Code for Each Case in Enum

I don't think I've ever wanted to distribute the patterns of a switch statement across multiple files. It seems like you want an enum of enums if the code you're writing needs this kind of chunking. Distributing cases is also far more brittle than the existing local switch; failing to include

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

Some simple questions: Say Tuples are deprecated and removed from the language: How would you go about pattern matching on multiple values in the same switch statement? What about pattern bindings for multiple values? When a function that takes more than one argument in a particular

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

Hi Robert, ok, I agree with you `obtain` could be bad replacement, that's why it's a draft. I’m not a native english speaker. In any case I’ve not problem the way it is now. Best Carlos > On 08 Jan 2017, at 08:11, Robert Widmann wrote: > > -1. This proposal is,

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

Don't remove tuples. They make it very convenient to pass multiple values around. Tuples use .0 instead of [0] which prevents any index out of bounds issues at compile time rather than at run time. Tuples should not adopt a dictionary style access because dictionaries imply nil for any key that

Re: [swift-evolution] [Pitch] Eliminate tuples - unify member access syntax

I think pattern matching is the most compelling reason to keep tuples. If they were gone, how would we replace the following? switch (a, b) { case (value1, value2): case (value3, value4): } On Sun, Jan 8, 2017 at 2:31 AM Derrick Ho wrote: > Don't remove tuples. > They make

Re: [swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

As a naming contrast, one could make Self like the proposed Current, and rename the current Self to DynamicSelf or something similar. Most protocols that are meant for value types in first place should use Self aka. Current as the return type. --  Adrian Zubarev Sent with Airmail Am 7.

[swift-evolution] [Pitch] Tweak `Self` and introduce `Current`

Hi Swift community, I’d like to talk to about current Self keyword. If I’m not totally mistaken then the current Self has a few meanings: Refer to the current type, or refer to the dynamic type for non-final classes inside containing type (SE–0068 - not yet implemented). For non-final class