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

> On Jan 7, 2017, at 10:02 AM, Adrian Zubarev via swift-evolution > wrote: > > 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

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

-1 from me. It doesn't really pay for itself. On Sun, Jan 8, 2017 at 2:26 PM, Derrick Ho via swift-evolution < swift-evolution@swift.org> wrote: > *if let *is fine the way it currently is. It may be strange to newcomers > since it is unique, but once you get used to it, it is super useful. > >

Re: [swift-evolution] Cancelable named defer statements

Its probably better to use a Boolean variable close_file to "cancel" it, rather than change the entire language. func openFile(kind: String) -> UnsafeMutablePointer? { var file = fopen("MyFile.txt", "r") var close_file = true defer { if close_file { fclose(file) }} // <-- if

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

*if let *is fine the way it currently is. It may be strange to newcomers since it is unique, but once you get used to it, it is super useful. On Sun, Jan 8, 2017 at 7:58 AM Georgios Moschovitis via swift-evolution < swift-evolution@swift.org> wrote: > I quite really like the `if let` syntax,

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

Currently we can write a helper method to aid in getting the values inside the enum associated value. Below is a fully working implementation: ``` enum Package { case box(String, Int) case circular(String) var associated: Associated { return Associated(package: self) } struct Associated {

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

On Jan 7, 2017, at 23:37, Derrick Ho wrote: 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): } I really have to ask. What do

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

That would be fine. > On Jan 8, 2017, at 10:31, Micah Hainline wrote: > > Perhaps we could limit further discussion here to the idea the original > poster put forth about eliminating mixed named and unnamed tuple labels.

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

On Jan 8, 2017, at 09:33, Freak Show wrote: >> On Jan 7, 2017, at 22:51, David Sweeris wrote: > >> A really convenient way to pass around multiple values without having to >> bother with a formal struct. > > That's actually a big part of my concern.

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

I feel that this thread has reached the predictable consensus conclusion that we should not eliminate tuples. Perhaps we could limit further discussion here to the idea the original poster put forth about eliminating mixed named and unnamed tuple labels. > On Jan 8, 2017, at 12:23 PM, Tony

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

On Sun, Jan 8, 2017 at 9:33 AM Freak Show via swift-evolution < swift-evolution@swift.org> wrote: > On Jan 7, 2017, at 22:51, David Sweeris wrote: > A really convenient way to pass around multiple values without having to bother with a formal struct. That's actually a big

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

> On Jan 8, 2017, at 06:53, Karim Nassar via swift-evolution > wrote: > > One area of enums that I’d love to see some sugar wrapped around (and perhaps > this has already been discussed previously?) is extracting associated values. > > There are many times where,

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

> On Jan 7, 2017, at 22:51, David Sweeris wrote: > A really convenient way to pass around multiple values without having to > bother with a formal struct. That's actually a big part of my concern. The people on this list are, I'm certain, among the top programmers

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

On Sun, Jan 8, 2017 at 4:09 AM, Adrian Zubarev < adrian.zuba...@devandartist.com> wrote: > There are a few good points made here. It’s an interesting workaround to > use type(of:) to get a similar behavior I wanted. My point is, that > Current or call it static Self should exist to fill some gaps

Re: [swift-evolution] Enhanced Existentials

> On 8 Jan 2017, at 06:17, Douglas Gregor via swift-evolution > wrote: > > > > 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 >>>

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

Although I appreciate the intent, I too find the proposed sugar far more noisy and harder to read than the more typical approach. But: TLDR; Simplifying the accessing of enum associated values would be worthy of some syntactic sugar in my opinion. One area of enums that I’d love to see some

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

Apart from your seeming distain for Swift, this proposal seems misguided to me, and to ignore some of the recent discussion around named parameters on tuples (which are currently in flux). Each of the types you mention each have clear, specific meanings. The following two are basic type system

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

I quite really like the `if let` syntax, feels natural to me. -1 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

There are a few good points made here. It’s an interesting workaround to use type(of:) to get a similar behavior I wanted. My point is, that Current or call it static Self should exist to fill some gaps in our design patterns. Using Self in protocols should not always mean that you shall use

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

+1 as for compleax enums it really does get messy. Leave the current approach in place, though. I'm not sure the syntax is best though. Maybe we could just open a curly brace right after the enum case declaration and put the specific function there. Same way everything out of the braces is

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

IMO the most problematic Self becomes in a generic context, i.e.: (pseudo code below) protocol Monad { associatedtype A func flatMap(f:(A)->Monad) -> ErasedSelf } I would really like to have this ErasedSelf. On Sun, 8 Jan 2017 at 5:21 Xiaodi Wu via swift-evolution < swift-evolution@swift.org>

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

-1 to obtain, unwrap and such. +1 to removing optional pattern in favor of normal if-pattern, plus removing case: if let unwrapped? = optionalValue { ... } ​ ___ swift-evolution mailing list swift-evolution@swift.org