Re: [swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

> Of course, if you’re worried about the performance costs associated with that > extra method call, you might want to include a keyword, such as “observable”, > and only generate the method call(s) if that keyword is on the property. I strongly agree that Swift should have/keep a possibility

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

This is a neat idea. Here are some of my thoughts after initial readthrough: - For symmetry with Obj-C code, how about using "@selector", such as @selector(UIView.`insertSubview(_:at:)`) ? - Or, why bother with a new expression? Could the compiler just do this automatically when it encounters an

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Given that someView.insertSubview(_:at:) can be correctly parsed, I would strongly lean towards the no-backtick alternative mentioned at the end. I feel as though the backticks end up looking very cluttered (particularly when you get into the double-nested backticks), and it seems cleaner to be

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

I have to agree with Frederick that the two-backticks example looks horrible ;-). I guess the # way worjs better in that case. I’m not entirely sure about his second remark: if we require that references to functions without arguments are written without parenthesis, don’t we then have some

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Some more things to consider: - Our naming conventions encourage the first parameter to most methods to be unlabeled, so unlabeled parameters come up a lot. I don't think there's a grammatical requirement for an identifier before each colon; maybe we can leave out the underscore and use

Re: [swift-evolution] swift-evolution Digest, Vol 1, Issue 237

I think that throwing out our effort is bed idea. Waiting for reflection system may cause that implementation of attributes will be impossible - both of those things should be done together! Maybe it would be good to work on agile, iterative bases? What do you think about defining for MVP -

Re: [swift-evolution] Failable Initializer Suggestion

> How do you guys think of that? Makes sense. Failable init has its roots in Objective-C, throws is a better fit for Swift — but it is not trivial to change all Cocoa class to throw instead of returning nil (at least in theory — most likely many classes don't have that many reasons for a

Re: [swift-evolution] Beef up Imports

The 'except' change is interesting, but it's still a context switch that can wind up confusing people. I think that's partly why Agda has the 'renaming' operation separate in the first place. ~Robert Widmann 2015/12/27 10:30、T.J. Usiyan via swift-evolution のメッセージ:

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

I would add to what Joe mentioned above the fact that the concept of "selector" may not mean a whole lot to developers who are first introduced to Swift without any prior Obj-C or Cocoa experience. Thinking of them as functions I believe avoids introducing complexity in the form of additional

Re: [swift-evolution] Beef up Imports

> On 27 Dec 2015, at 07:12, Developer via swift-evolution > wrote: > > Therefore, I propose the introduction of 3 agda-esque operations for imports > to replace the usual `import {func|typealias|struct|class|enum|etc.}` syntax: > > • import Foo using (bar,

Re: [swift-evolution] Beef up Imports

*import* Foo *using* (bar, Baz, qux, waldo *as* fred) // a "whitelist import" *import* Foo *hiding* (bar, Baz, qux, waldo *as* fred) // a "blacklist import" Is nice but `hiding… (waldo as fred)` is confusing. Am I hiding waldo? It is also strange to look in that list for things that I am

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

> On 27 Dec 2015, at 21:55, Mosab Elagha wrote: > > Agreed, this seems like a great idea. Looks like it would also allow for a > lot of customization - for example out of one "template" object. > > Would the object have to already be initialized or could you initialize

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

Hi, That’s a great idea! Kind regards, Radek > On 27 Dec 2015, at 21:10, Taras Zakharko via swift-evolution > wrote: > > Quite often, one needs to perform a number of operations on a single object > (e.g. call up a bunch of configuration or action methods). This

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

Great idea, but why make it a free function instead of a Selector initializer? let sel1 = Selector(UIView.`insertSubview(_:at:)`) let sel2 = Selector(UIView.`frame.get`) Of course if there were such a thing as GeneralizedFunctionNameLiteralConvertible, we could get a “free” conversion to

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution > wrote: > > Hi all, > > Here’s a proposal draft to allow one to name any function in Swift. In > effect, it’s continuing the discussion of retrieving getters and setters as > functions started by

Re: [swift-evolution] Lambda function syntax

Sorry, i misread you mail. Em dom, 27 de dez de 2015 às 23:20, Developer escreveu: > Oh my, no. I don't intend Swift to become the λ calculus, I was merely > making an analogy (and a joke, 3 replies ago). In the same way that λ is > the simplest set of rules

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

-1 doesn't seem worth adding it is not a lot of trouble to type `obj.` at the start of every line. Also if an API is intended to be used like that its methods would return `self` and it would be used in a FLUENT style. Sent from my iPad > On 28 Dec 2015, at 9:00 AM, Erica Sadun via

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

The most common use-case for this is with Cocoa classes, which are not set up for fluent implementation. A preliminary proposal (which I am not updating since the matter was referred to the bug report system) is here: https://gist.github.com/erica/6794d48d917e2084d6ed Hopefully it explains the

Re: [swift-evolution] User Defined Annotations

It can’t hurt to work on a proof of concept, but I think it’s worth exploring the space of possible designs before jumping too far into an implementation. I have some code that adds an “annotation” declaration and adds a new attribute kind for custom annotations, though it still needs some work

Re: [swift-evolution] [Idea] Add an (Index, Element) sequence to CollectionType

What you're asking for can already be done with `zip(col.indices, col)`. And in my experience the need for this sort of thing is rare enough that there's no need to have a dedicated property for it in the stdlib. The few times that I've needed this sort of thing, I've always just said for index

Re: [swift-evolution] Lambda function syntax

With a proper λ, that's the point. The lambda calculus doesn't focus on the delimiter between the binder and the body because it isn't the important part of an abstraction, the rest is. I would argue a programming language shouldn't either. What is to be gained by having more syntax around a

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

On Dec 27, 2015, at 4:09 PM, John McCall wrote: >> I’m a fan of good error recovery, but I don’t think it is a major concern >> here for two reasons: >> >> 1) The most common case in a method will lack a label, and "thing.foo(_: “ >> and “thing.foo(:” are both unambiguously

Re: [swift-evolution] [Pitch] Guarding on enum values

You actually can do simple let-bindings in if-let and guard-let via the `case let` syntax: guard case let r = returnsResult(), case let .Succeed(m) = r else { ... } Although the problem with this is `r` still isn't visible inside of the else block, because it's part of the guard statement and

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

Ah, thank you for pointing this out! I think I would suggest a change or two to your proposal, but I need to flesh them out first. Is it possible to leave comments on the bug site? BTW, why was it delegated to the bug report system in the first place? > On 28 Dec 2015, at 02:28, Erica Sadun

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

Same is true for the implicit self, and yet we’ve seen how people react to making self explicit. There are many places in contemporary Apple programming where this could be of great utility. For instance, I miss a lexical scope construction every time I work with Metal. > On 28 Dec 2015, at

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution wrote: >> can be correctly parsed as a reference to insertSubview(_:at:). However, it >> breaks down at the margins, e.g., with getter/setter references or >> no-argument functions: >> >> extension Optional

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Le 27 déc. 2015 à 19:54, Wallacy via swift-evolution a écrit : > Even with backticks would not be possible. > > You may need to reference the method signature altogether. > > var someA = A() > let fn1 = someA.#someFunc(a: Int) -> Int > let fn2 = someA.#someFunc(a:

Re: [swift-evolution] Lambda function syntax

Then you clear know nothing of the history of computer science. I repeat, the original syntax of the lambda calculus, to which you were referring, was *not* designed for readability. Its purpose was entirely different. This is only the start of the differences – there really isn’t anything to

Re: [swift-evolution] Lambda function syntax

Yes, please do. It is perfectly fine to disagree on technical points, but please do so with respect. -Chris > On Dec 27, 2015, at 3:44 PM, Austin Zheng via swift-evolution > wrote: > > Please treat your fellow contributors with respect and equanimity. > > Best, >

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

How to differentiate these functions? class A{ func someFunc(a: Int) -> Int{ return 0; } func someFunc(a: Int) -> Double{ return 0; } func someFunc(a: Double) -> Int{ return 0; } func someFunc(a: Double) -> Double{ return 0; }

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 4:27 PM, John McCall wrote: > >> On Dec 27, 2015, at 4:15 PM, Chris Lattner wrote: >> >> On Dec 27, 2015, at 4:09 PM, John McCall wrote: I’m a fan of good error recovery, but I don’t think it is a major

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution > wrote: > > Given that someView.insertSubview(_:at:) can be correctly parsed, I would > strongly lean towards the no-backtick alternative mentioned at the end. I > feel as though the

Re: [swift-evolution] Lambda function syntax

Now, now, that's no way to talk about a century's worth of computing research. Since you have yet to respond to my original point, I'll expound: I see Swift's choice of "in" in context of other programming languages that admit anonymous inner scopes with little fuss. Those tend to come from

Re: [swift-evolution] Lambda function syntax

Notation is not an arbitrary construct, and the choice of how to represent a λ-abstraction isn’t either. When Church designed the calculus, he chose just 3 simple constructs: variables, abstractions, and applications, to be the entirety of the language. Readability in the system is derived

Re: [swift-evolution] Lambda function syntax

Oh my, no. I don't intend Swift to become the λ calculus, I was merely making an analogy (and a joke, 3 replies ago). In the same way that λ is the simplest set of rules embodying the powerful construct abstraction is, Swift's syntax for it is probably the simplest and best we can get given

Re: [swift-evolution] Lambda function syntax

The lambda calculus is a mathematical tool. It’s not designed for readability. Your point is invalid. > On 27 Dec 2015, at 23:03, Developer wrote: > > With a proper λ, that's the point. The lambda calculus doesn't focus on the > delimiter between the binder and the

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

*"if you add a `someFunc` overload taking a different parameter name but the same types the above code becomes ambiguous."* Yes, I know, I forgot this example. Ironically that was the intent, but I do not choose good examples. I was just exploring the idea of having to display the full signature

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 4:02 PM, Chris Lattner via swift-evolution > wrote: > On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution > > wrote: >>> can be correctly parsed as a reference to

Re: [swift-evolution] [Proposal] Lexical scope statement (with .. do)

I think it would be of great value to post both here and at the bug itself. Thanks! -- E, looking forward to it > On Dec 27, 2015, at 8:22 PM, Taras Zakharko > wrote: > > Ah, thank you for pointing this out! I think I would suggest a change or two > to your

Re: [swift-evolution] Lambda function syntax

By almost everybody that's actually posted to this thread. That's a hugely important distinction. Personally, I like "in". -Kevin Ballard On Sun, Dec 27, 2015, at 02:56 PM, Alexander Regueiro via swift-evolution wrote: > It’s been agreed by almost everyone that “in” is at the very least a poor

Re: [swift-evolution] Lambda function syntax

Just reread my reply and found it a bit unclear, so I'm trying to fix that below :-) > Am 28.12.2015 um 07:08 schrieb Thorsten Seitz via swift-evolution > : > > > Am 27.12.2015 um 23:24 schrieb Brent Royal-Gordon via swift-evolution > : >

Re: [swift-evolution] [Pitch] Guarding on enum values

> Am 28.12.2015 um 02:31 schrieb Kevin Ballard via swift-evolution > : > > You actually can do simple let-bindings in if-let and guard-let via the `case > let` syntax: > > guard case let r = returnsResult(), case let .Succeed(m) = r else { ... } > > Although the

[swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

## Introduction Add a new property `cycle` to CollectionType that returns an infinite SequenceType that yields the elements of the collection in a loop. ## Motivation It's sometimes useful to be able to have an infinite sequence. For example, `CollectionOfOne(x).cycle` could be used to have

Re: [swift-evolution] Proposal: CollectionType.cycle property for an infinite sequence

+1. Stream support is long overdue. ~Robert Widmann 2015/12/28 2:20、Kevin Ballard via swift-evolution のメッセージ: > ## Introduction > > Add a new property `cycle` to CollectionType that returns an infinite > SequenceType that yields the elements of the collection in

Re: [swift-evolution] [Idea] Add an (Index, Element) sequence to CollectionType

> What you're asking for can already be done with `zip(col.indices, col)`. And > in my experience the need for this sort of thing is rare enough that there's > no need to have a dedicated property for it in the stdlib. The few times that > I've needed this sort of thing, I've always just said >

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

Commentary inline below. FKL > On Dec 27, 2015, at 8:40 PM, Douglas Gregor wrote: > > >> On Dec 27, 2015, at 12:27 AM, Frederick Kellison-Linn via swift-evolution >> wrote: >> >> Given that someView.insertSubview(_:at:) can be correctly parsed,

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> Am 28.12.2015 um 01:15 schrieb Chris Lattner via swift-evolution > : > > (just a strawman, intentionally ugly syntax): > >foo.#bar Much prettier than backticks IMHO. -Thorsten ___ swift-evolution mailing list

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> So “try” instead of “do”. If there is no catch, then just use braces without > a keyword for a block. > > And use do-while instead of repeat-while. Do you also propose no longer marking calls to throwing functions with `try`? Have you read the "Error-Handling Rationale" document in the