Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

+1. The proposal wasn’t explicit enough to have either supported or be against this IMO. It’s a sensible thing to spell out. Daniel Duan Sent from my iPhone > On Dec 15, 2017, at 9:58 AM, Joe Groff via swift-evolution > wrote: > > SE-0185 is awesome, and brings the

Re: [swift-evolution] [Pitch] Raw mode string literals

I eh, literally just ran into a situation where this feature would have been super useful: Someone sent me a JSON string with “\” in it. I needed to plug it into the UI logic to test something but I had to escape the “\”s again to make JSONSerialization happy. A raw string literal syntax,

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 3, 2017, at 1:35 PM, Xiaodi Wu via swift-evolution > wrote: > > The desired behavior was the major topic of controversy during review; I’m > wary of revisiting this topic as we are essentially relitigating the proposal. > > To start off, the premise, if I

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 11, 2017, at 5:50 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution > > wrote: > >> On Apr 11, 2017, at 8:08 AM, Adrian

Re: [swift-evolution] Enhancing access levels without breaking changes

This never went into a review. The pull request is still open https://github.com/apple/swift-evolution/pull/587 > On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution > wrote: > > I don't want to make any change until Chris has been able to chime in. If he >

Re: [swift-evolution] Reduce with inout

Ping. What’s the latest on this proposal? Seems like a clear win to me. It seems the thread converged on a name if we want 2 versions of reduce. Should we simply replace the existing version so there’s only one? Really wish this can get in Swift 4. > On Jan 25, 2017, at 1:06 AM, Chris Eidhof

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 10, 2017, at 10:52 AM, Matthew Johnson wrote: > > >> On Apr 10, 2017, at 12:48 PM, Daniel Duan wrote: >> >> No offense taken. >> >> There's no inherent problem with designing language with available tools in >> mind. After all, what we put

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

No offense taken. There's no inherent problem with designing language with available tools in mind. After all, what we put in the language is a strict subset of what's viable in a compiler. IMHO Swift should care more about separation of language and tools due to its long-term ambition: is

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

ng >>> like opt-click in Xcode. I don’t think it’s worth cluttering up our code >>> with annotations that are readily available to most readers. Most of the >>> time annotations introduce noise that reduces clarity. I don’t think >>> relying on tools in the occasional cas

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

iel Duan >> Sent from my iPhone >> >>>> On Apr 10, 2017, at 9:16 AM, Matthew Johnson <matt...@anandabits.com> >>>> wrote: >>>> >>>> >>>> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution >>>&

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

l variable is less likely. Daniel Duan Sent from my iPhone > On Apr 10, 2017, at 9:16 AM, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On Apr 10, 2017, at 11:11 AM, Daniel Duan via swift-evolution >> <swift-evolution@swift.org> wrote: >> &

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

tory is sketchy. >>> On Apr 10, 2017, at 8:55 AM, Sean Heber <s...@fifthace.com> wrote: >>> >>> This is not really a helpful comment, but: I kinda wish they did. >>> >>> l8r >>> Sean >>> >>>> On Apr

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

comment, but: I kinda wish they did. > > l8r > Sean > >> On Apr 10, 2017, at 10:54 AM, Daniel Duan via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Neither of these works btw. >> >> func bar(myString = “hello”) >> clas

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

posal anyways: >> https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55 >> <https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55> >> >>> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolut

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

I’m still not sure whether *I* want this. But here’s a proposal anyways: https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55 <https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55> > On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution > <swift-evol

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

Daniel Duan Sent from my iPhone > On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution > wrote: > > Hi, John here, the submitter of the proposal. > > First up, I must apologise for putting Brent on the spot when I resubmitted > this altered proposal

[swift-evolution] [Pitch] Remove type-inference for stored property

Hi all, In a discussion about inferring parameter types from default value, Slava brought up some performance problems caused by type inference for stored properties in side types: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033882.html Towards the end, the post

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

This use case has at least been brought up in discussions within my team. I wouldn't be surprised if it's actually deployed as well. Given a big project with enough experienced devs, I'd say this pattern is almost a certainty. Daniel Duan Sent from my iPhone > On Apr 6, 2017, at 6:53 PM, Brent

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> • What is your evaluation of the proposal? I support the initiative. But I have the question as Greg and Tony: how would one write “”” in side the literal? > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > • Does this proposal fit

Re: [swift-evolution] Type-based ‘private’ access within a file

gt;> wrote: >>>> >>>>> >>>>> On 3 Apr 2017, at 22:54, Douglas Gregor via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> >>>>&

Re: [swift-evolution] Type-based ‘private’ access within a file

I’m concerned that we will have access control changes in a future version yet again, when light-weight modules, or other type of enforced namespace is introduced. Does the core team have any foresight on how this change would interact with such things? I had the same concern for SE-0159 as

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

! > On Mar 31, 2017, at 6:38 PM, Daniel Duan via swift-evolution > <swift-evolution@swift.org> wrote: > > nit: should these names be `all(matching)`/`all(equalTo)` per API Design > Guidelines? >> On Mar 31, 2017, at 8:28 AM, Ben Cohen via swift-evolution &g

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

of long/short forms: case .color(hue: _, _, let alpha): // yuck > On Apr 2, 2017, at 11:46 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Apr 2, 2017, at 11:17 PM, Daniel Duan via swift-evolution >> <swift-evolution@swift.org <mailto:

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

That seems like straight up ambiguity with or without restriction on the label though? This kind of usability problem should and is discouraged by the proposed solution. > On Apr 2, 2017, at 11:10 PM, Xiaodi Wu wrote: > > On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

> On Apr 1, 2017, at 2:54 PM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan > wrote: > Thanks again for a detailed review. I have a few comments inline. > >> On Apr 1, 2017, at 9:50

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

Thanks again for a detailed review. I have a few comments inline. > On Apr 1, 2017, at 9:50 AM, Xiaodi Wu via swift-evolution > wrote: > > • Does this proposal fit well with the feel and direction of Swift? > > The "Pattern consistency" section does not align

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

nit: should these names be `all(matching)`/`all(equalTo)` per API Design Guidelines? > On Mar 31, 2017, at 8:28 AM, Ben Cohen via swift-evolution > wrote: > > Hi, > > A short proposal for you as part of the algorithms theme. Hopefully > non-controversial, aside

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> What is your evaluation of the proposal? -1 > Is the problem being addressed significant enough to warrant a change to > Swift? Here lies the core reason for my down vote. There are currently 3541 occurrences of 'private' and 635 'fileprivate' in the code base I work on regularly. Without

Re: [swift-evolution] [Draft] Anonymous Enum Cases

t; Sent with Airmail > > Am 9. März 2017 um 15:00:48, Matthew Johnson via swift-evolution > (swift-evolution@swift.org) schrieb: > >> +1. Combining this with overloaded cases will be very nice for some kinds of >> enums. >> >> Sent from my iPad >>

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

Here’s an updated version with hopefully the correct content. The “overloaded” case feature has been removed and is discussed in the "alternatives considered" section. # Normalize Enum Case Representation * Proposal: [SE-0155][] * Authors: [Daniel Duan][], [Joe Groff][] * Review Manager:

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

cc’ing Xiaodi > On Mar 9, 2017, at 1:53 PM, Joe Groff <jgr...@apple.com> wrote: > > >> On Mar 8, 2017, at 7:09 PM, Daniel Duan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hi everyone,

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

> On Mar 9, 2017, at 12:31 AM, Xiaodi Wu wrote: > > On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan > wrote: > Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to > incorporate some of the responses into the

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

> On Mar 9, 2017, at 12:06 AM, David Hart <da...@hartbit.com> wrote: > > >> On 9 Mar 2017, at 08:07, Daniel Duan via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm g

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to incorporate some of the responses into the proposal. > On Mar 8, 2017, at 9:56 PM, Xiaodi Wu wrote: > > The rendered version differs from the text appended to your message. I'll > assume the more

[swift-evolution] Normalize Enum Case Representation (rev. 2)

Hi everyone, Here’s revision 2 of SE-0155. I’d love some feedback before going into re-review. Note the “anonymous case” feature is not in this proposal. I found the motivation section difficult to write when it’s included. I’ve drafted a separate proposal that adds it. Rendered version:

[swift-evolution] [Draft] Anonymous Enum Cases

Hi all, During review for the first revision of SE-0155, Dave Abraham suggested that we should allow enum cases without base names. So here’s a (rough) draft of a proposal for this feature. Please read and share your thoughts! # Anonymous Enum Cases * Proposal:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Daniel Duan Sent from my iPhone > On Feb 27, 2017, at 10:00 AM, Joe Groff wrote: > > >> On Feb 24, 2017, at 9:26 PM, Daniel Duan wrote: >> >> Before I start revising this proposal, there are a couple of open questions >> I’d like to discuss with the

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

Not sure which “this” you were referring to. The anonymous case part is something that I consider out-of-scope for this proposal as well. It came up during review and is posted as one of the core team’s request. There are two possibilities regarding this feature: I can put it in future

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 25, 2017, at 6:13 AM, Matthew Johnson <matt...@anandabits.com> wrote: > > > > Sent from my iPad > > On Feb 24, 2017, at 11:26 PM, Daniel Duan via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: &

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> My apologies fo

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Thanks. I already planned to do a revision to address these questions, which all came up during the review. > On Feb 22, 2017, at 11:27 AM, John McCall <rjmcc...@apple.com> wrote: > >> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution >> <swift-evolut

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

FWIW, I like the freedom of choice. A Java-like file-based solution can be limiting for *some* style of programming. It is, as Robert mentioned, geared towards benefit of the implementation. I also suspect ppl who are asking for file-based solution _now_ may find themselves wanting the

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

wrote: >> On Feb 21, 2017, at 1:28 AM, Daniel Duan via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> It has been my hope that a lightweight module system will remove the need >> for `private` *and* `fileprivate`. > > I really doubt it will. `p

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

My apologies for misunderstanding. Would it be better to add the anonymous case feature in a separate proposal? It stands alone as a new addition to enum. The intent for this proposal is bringing enum's syntax closure to other part of Swift. Daniel Duan Sent from my iPhone > On Feb 21, 2017,

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution >> > wrote: >> >> I'm on vacation and don't have time

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Hi Dave, > On Feb 18, 2017, at 8:49 PM, Dave Abrahams via swift-evolution > wrote: > > I'm on vacation and don't have time for a full review right now, but I am > concerned that wild this proposal would make enums more general and uniform > with the rest of the

Re: [swift-evolution] [Draft] @selfsafe: a new way to avoid reference cycles

This reminded me of an idea I had long time ago which will have a similar effect: add a way to disable implicit captures for closures. FWIW. > On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution > wrote: > > # `@selfsafe`: a new way to avoid reference

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

> On Feb 18, 2017, at 8:47 AM, Matthew Johnson via swift-evolution > wrote: > > >> • What is your evaluation of the proposal? > > +1. I am extremely confident that this is the right direction to go in. > > I really like Brent’s idea for allowing us to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

Hi Brent, > On Feb 18, 2017, at 3:49 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 17, 2017, at 7:26 PM, John McCall wrote: >> >> Proposal link: >>

Re: [swift-evolution] [Review] SE-0155: Normalize Enum Case Representation

Hi Slava, > On Feb 18, 2017, at 12:30 AM, Slava Pestov via swift-evolution > wrote: > > +1, two small questions: > > - If two cases have the same base name but different full names, will > matching on the base name match both cases, or will it be an error? An

Re: [swift-evolution] [Discussion] mailing list alternative

> On Feb 7, 2017, at 1:23 PM, Daniel Duan via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Feb 7, 2017, at 1:15 PM, Tino Heth <2...@gmx.de <mailto:2...@gmx.de>> >> wrote: >> >>> Believe it or not, not every

Re: [swift-evolution] [Discussion] mailing list alternative

> On Feb 7, 2017, at 1:15 PM, Tino Heth <2...@gmx.de> wrote: > >> Believe it or not, not everyone in the world can afford the device and data >> plan for a JavaScript-rich web front end (I'm aware of the mobile apps). I >> remember only being able to buy an iPod Touch myself when it came out.

Re: [swift-evolution] [Discussion] mailing list alternative

Turns out it’s possible to retroactively participate a thread that one hasn’t subscribed to. An example of it happening is here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031544.html

Re: [swift-evolution] [Discussion] mailing list alternative

Terribly sorry for spamming. This will be the last one. I've added the `In-Reply-To` header to thunderbird and included the correct (hopefully!) value from a previous, on-thread message. This email address was not subscribed to the thread. ___

Re: [swift-evolution] [Discussion] mailing list alternative

Here's attempt #2 from Thunderbird. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] mailing list alternative

Here’s my attempt to chime in an existing thread from a newly subscribed email address. > This may help > > http://webapps.stackexchange.com/questions/23197/reply-to-mailman-archived-message > >

Re: [swift-evolution] [Discussion] mailing list alternative

Mail.app grouped it in the correct thread (further proves that email clients are awesome ). Unfortunately mailman did not do so. > On Feb 6, 2017, at 4:40 PM, James Berry <jbe...@rogueorbit.com> wrote: > >> On Feb 6, 2017, at 4:28 PM, Daniel Duan via swift-evolution &

Re: [swift-evolution] [Discussion] mailing list alternative

or other > reasons, too). > > (I can see an O’Rly book titled “Advanced Mailing List” in my mind right now > ). > >> On Mon, Feb 6, 2017 at 17:24 Daniel Duan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: &g

Re: [swift-evolution] [Discussion] mailing list alternative

ote this happens in forums for other reasons, too). (I can see an O’Rly book titled “Advanced Mailing List” in my mind right now ). > On Mon, Feb 6, 2017 at 17:24 Daniel Duan via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] [Discussion] mailing list alternative

> On Feb 6, 2017, at 3:02 PM, Chris Hanson via swift-evolution > wrote: > > On Feb 2, 2017, at 2:24 PM, James Berry via swift-evolution > > wrote: >> >> Speaking for myself only, discourse seems to give

Re: [swift-evolution] Warn about unused Optional.some(())

> On Feb 6, 2017, at 11:35 AM, Jordan Rose wrote: > >> >> On Feb 6, 2017, at 11:08, Daniel Duan > > wrote: >> >> >>> On Feb 6, 2017, at 10:58 AM, Jordan Rose >> > wrote:

Re: [swift-evolution] Warn about unused Optional.some(())

'@discardableResult > Optional' or whatever, but I think that's probably more work than > anyone wants to sign up for. I’ll give this a go and report back. *crosses fingers* > > Jordan > > >> On Jan 31, 2017, at 08:16, Daniel Duan via swift-evolution >> &l

Re: [swift-evolution] [draft] Compound Names For Enum Cases

labels? > > enum Foo { > case foo(a: Int) > case foo(a: Int, b: Int) > } > Is Foo a valid enum after this proposal? > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 19. Januar 2017 um 19:37:50, Daniel Duan via swift-evolution > (swift-evolutio

Re: [swift-evolution] Warn about unused Optional.some(())

;> regularly occurs with weak variables, e.g. captures in closures). >> >> So much for the history of this feature. >> >> – Alex >> >> >>> On 30 Jan 2017, at 22:58, Daniel Duan via swift-evolution >>> <swift-evolution@swift.org> wro

Re: [swift-evolution] Warn about unused Optional.some(())

m we decided to move > to a consistent model where ()?, ()??, … is always discardable since we > didn't want to take the convenience of foo?.bar() away (something that > regularly occurs with weak variables, e.g. captures in closures). > > So much for the history of this feature. &g

Re: [swift-evolution] Warn about unused Optional.some(())

t;> <swift-evolution@swift.org> wrote: >> >> >> >> Sent from my iPad >> >>> On Jan 30, 2017, at 5:25 PM, Slava Pestov via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>>> On Jan 30,

Re: [swift-evolution] Warn about unused Optional.some(())

t; > Begin Message > Group: gmane.comp.lang.swift.evolution > MsgID: <1fa68175-bc14-4e61-aece-a80b79d55...@apple.com> > > >> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution >> <swift-evolution@swift.org> wrote: >>

Re: [swift-evolution] Warn about unused Optional.some(())

Not sure if this requires a proposal. The code change is pretty trivial: https://github.com/apple/swift/pull/7154 <https://github.com/apple/swift/pull/7154> . > On Jan 30, 2017, at 3:25 PM, Slava Pestov <spes...@apple.com> wrote: > >> >> On Jan 30, 2017, at

[swift-evolution] Warn about unused Optional.some(())

Hi all, Right now, expressions that evaluates to Optional<()>, Optional>… gets special treatment when it’s unused. For example: func f(s: String) {} let s: String = “” s.map(f) // no warning here, even tho the resulting type is `Optional<()>` and unused. func g() throws {} try?

Re: [swift-evolution] [Discussion] mailing list alternative

This is amazing! It solved the biggest complaint a few of us have with the current archive! > On Jan 26, 2017, at 1:36 PM, Tyler Stromberg via swift-evolution > wrote: > > on Thu Jan 26 2017, Dave Abrahams wrote: > > on Thu Jan 26 2017, Nate Cook >

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 26, 2017, at 10:49 AM, Adrian Zubarev > wrote: > > There are official mobile apps for Discourse: iOS > & > Android . >

Re: [swift-evolution] [Discussion] mailing list alternative

I'm actually convinced that I'd rather use an email client. Having to participate in a web app is a regression in my experience. Daniel Duan Sent from my iPhone > On Jan 26, 2017, at 10:15 AM, Adrian Zubarev via swift-evolution > wrote: > > Awesome :) Hopefully

Re: [swift-evolution] Optional Assignment Operator

-1 I personally think Optional has received too much special treatment in the language already. I’ve known folks who have written Swift professionally for almost a year until they realize Optional is just an enum. More magic syntax around it would only make this worse. > On Jan 25, 2017, at

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> >> >> >> On Tue, Jan 24, 2017 at 17:16 Christopher Kornher via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> On Jan 24, 2017, at 4:02 PM, Daniel Duan <dan...@duan.org >>> <mailto:da

Re: [swift-evolution] [draft] Compound Names For Enum Cases

t 3:16 PM, Christopher Kornher <ckorn...@me.com> wrote: > >> >> On Jan 24, 2017, at 4:02 PM, Daniel Duan <dan...@duan.org >> <mailto:dan...@duan.org>> wrote: >> >> >> >> Daniel Duan >> Sent from my iPhone >> >&g

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Daniel Duan Sent from my iPhone > On Jan 24, 2017, at 2:53 PM, Daniel Duan via swift-evolution > <swift-evolution@swift.org> wrote: > > > > Daniel Duan > Sent from my iPhone > >> On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Daniel Duan Sent from my iPhone > On Jan 24, 2017, at 2:18 PM, Christopher Kornher via swift-evolution > wrote: > > I agree that this rule would be consistent with the handing of Swift > function signatures, but my proposal is self-consistent and: > > 1) It is

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Great suggestion. Done. > On Jan 24, 2017, at 5:07 AM, David Hart via swift-evolution > wrote: > > Ok, sounds logical. Might be worth adding that info to the proposal to make > it clear how ambiguity plays out. > >> On 24 Jan 2017, at 13:27, Xiaodi Wu

Re: [swift-evolution] [draft] Compound Names For Enum Cases

roduce a rule that >> matches >> all associated values to a labeled tuple. As T.J. Usiyan >> [pointed out][TJs comment], implementation of the equality protocal would be >> simplified due to tuple's conformance to `Equatable`. This feature may still >> be >> i

Re: [swift-evolution] [draft] Compound Names For Enum Cases

n-20170116/030614.html [SE Thread]: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170116/030477.html > On Jan 19, 2017, at 10:37 AM, Daniel Duan via swift-evolution > <swift-evolution@swift.org> wrote: > > Hi all, > > Here’s a short proposal for fixing an

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 22, 2017, at 11:26 AM, Matthew Johnson wrote: > > >> On Jan 22, 2017, at 3:51 AM, Robert Widmann via swift-evolution >> > wrote: >> >> Sure. One of the first gadgets I wrote was a way of

Re: [swift-evolution] [draft] Compound Names For Enum Cases

This would be a real loss . Another nice thing we would be losing is tuple field labels *after* matching: if case let .bar(a) = Foo.bar(x: Int, y: Int) { doThings(with: a.x, a.y) } Keeping them means we have the create a special (reverse)splatting rule for pattern matching. I can see a few

Re: [swift-evolution] [draft] Compound Names For Enum Cases

FWIW, in all public Github repos with 5k+ stars whose language gets recognized as “Swift”, 576 enum cases has associated values and among them 55 has 2 values or more. After some very casual grepping I didn’t find a lot of usage of this particular pattern. Care to share some examples, Robert?

Re: [swift-evolution] [draft] Compound Names For Enum Cases

e bar: ... > } > > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Swiftrien > Project: http://swiftfire.nl > > > > >> On 19 Jan 2017, at 19:37, Daniel Duan via swift-evo

Re: [swift-evolution] [draft] Compound Names For Enum Cases

with a `.foo(let q, let z)` or > `.foo(apples: let x, bananas: let y)` pattern. We should probably tighten > that up as part of this proposal as well. > > -Joe > >> 2) I wouldn’t blame you if you wanted to slip in default arguments for >> associated values here, because th

[swift-evolution] [draft] Compound Names For Enum Cases

Hi all, Here’s a short proposal for fixing an inconsistency in Swift’s enum. Please share you feedback :) (Updating/rendered version: https://github.com/dduan/swift-evolution/blob/compound-names-for-enum-cases/proposals/-Compound-Names-For-Enum-Cases.md

Re: [swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

> On Nov 6, 2016, at 1:20 PM, Dave Abrahams via swift-evolution > wrote: > > A construct that is only conditionally unsafe > shouldn't be spelled "unsafe" when used in a safe way, right? So this > *seems* to argue for an "unsafe" keyword that can be used to label >

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

flexible for cases where it’s not flexible. No one should decide those cases for anyone!) The value added is well explained in the proposal. Simply saying “Cocoapods is good enough, why don’t we copy it” isn’t very constructive and interesting to me. > Sent from my iPhone > >> On 3

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

Daniel Duan Sent from my iPhone On Nov 2, 2016, at 11:17 PM, Martin Waitz wrote: >> Am 03.11.2016 um 03:22 schrieb Daniel Duan : >> On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution >> wrote: >> What is your

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

On Nov 2, 2016, at 3:46 PM, Martin Waitz via swift-evolution wrote: >> What is your evaluation of the proposal? > > +1 for using reproducible versions of dependencies > -1 for the actual proposal > > My problem with this proposal is that it tries to please everybody

Re: [swift-evolution] [Review] SE-0145: Package Manager Version Pinning

> > * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes, version pinning is very important to dependency management in production environments. > * Does this proposal fit well with the

Re: [swift-evolution] [Proposal] Refining Identifier and Operator Symbology

It’s worth pointing out that the proposal to add ‘$’ to identifiers is still under active review and have generated much controversy. I wouldn’t put much weight in “backward compatibility” for that proposal. > On Oct 21, 2016, at 9:38 PM, Jonathan S. Shapiro via swift-evolution >

Re: [swift-evolution] Some clarity lost from the great renaming

I wrote a script to find “needless words” in our function names and made a similar discovery. If “doXWithY(_ y: Y)” gets renamed to “doX(with y: Y)” and Y happened to be a enum or have static members, at use site it become a little awkward. Following Brandon’s first example: 1. “normal” is an

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

> On Oct 14, 2016, at 3:42 PM, Alex Martini via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Oct 14, 2016, at 1:53 PM, Hooman Mehr via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

Agree with Robert here. I'd rather be able to use it as part of operators. Currently the character set for operators and identifier head are mutually exclusive. So this proposal will remove that possibility. This deserves some discussion. Daniel Duan Sent from my iPhone > On Oct 14, 2016, at

Re: [swift-evolution] [swift-build-dev] Proposal: Package Manager Version Pinning

The spelling nitpick should have been on GitHub in retrospect. I wrongly assumed everyone know of our preference for dialect :) Point 1-7 are all concrete descriptions of features. That's probably why the SHA point feels out-of-place. Perhaps it deserves its own section. > On Oct 14, 2016, at

Re: [swift-evolution] Proposal: Package Manager Version Pinning

d easy to refer to > pronunciation rules ;). It needs reforming :P, but let's keep it for > English-Evolution ;). > > Sent from my iPhone > >> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> &

Re: [swift-evolution] private & fileprivate

a pre-existing incompatible meaning in programming (otherwise it would be > great), or “folio” which is not an adjective (and also isn’t ideal for the > single-file case). > > But “privy” just might work. > > Nevin > > >> On Thu, Oct 13, 2016 at 10:44 PM, Daniel Du

Re: [swift-evolution] Proposal: Package Manager Version Pinning

This is a familiar feature among package managers and has been proven useful in practice. Two points regarding the proposed text: 1. “honor” is mis-spelled in “weird queen’s dialect”. 2. SHA/man-in-the-middle attack section needs either more detailed explanation/reference materials, or

Re: [swift-evolution] private & fileprivate

I question the practicality of "use private heavily simply because I don’t want the burden of mixing private and fileprivate". In our experience in converting a very mature Swift application, we had no choice but to use both because we wanted private as much as possible but that's too

  1   2   >