Re: [swift-evolution] History and future of Swift's parentheses

Ok, I understand, thanks! On Mon, Jun 12, 2017 at 9:29 PM, John McCall wrote: > On Jun 12, 2017, at 3:13 PM, Jens Persson wrote: > On Mon, Jun 12, 2017 at 8:52 PM, John McCall wrote: >> >> >> We really do want to tie most of these features specifically to function >> calls. >> > > > I'm not su

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 12, 2017, at 3:13 PM, Jens Persson wrote: > On Mon, Jun 12, 2017 at 8:52 PM, John McCall > wrote: > > We really do want to tie most of these features specifically to function > calls. > > > I'm not sure if I understand what you mean. Do you mean that you re

Re: [swift-evolution] History and future of Swift's parentheses

On Mon, Jun 12, 2017 at 8:52 PM, John McCall wrote: > > > We really do want to tie most of these features specifically to function > calls. > I'm not sure if I understand what you mean. Do you mean that you really don't want these features to require changes to the type system? My main problem/

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 12, 2017, at 2:36 PM, Jens Persson via swift-evolution > wrote: > > > On Mon, Jun 12, 2017 at 7:13 PM, Michael Ilseman > wrote: > > * Unless you’re proposing a change to the semantics of the language that > could affect e.g. name mangling or the type meta

Re: [swift-evolution] History and future of Swift's parentheses

On Mon, Jun 12, 2017 at 7:13 PM, Michael Ilseman wrote: > > > * Unless you’re proposing a change to the semantics of the language that > could affect e.g. name mangling or the type metadata hierarchy, then that > would be ABI-affecting. For example, proposing that all functions must only > take a

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 4:34 PM, Jens Persson wrote: > > The analogy of the special first parameter label was relevant (for me) in > that it was a special rule that was invented to resolve a problem/situation > with no clear best solution. Probably most people agree now that the current > simple

Re: [swift-evolution] History and future of Swift's parentheses

You can kinda do this already: func foo(_ parameter: inout ParameterType) { var shortcut: TheType { get { return parameter.very.very.long.and.tedious.inout.member } set { parameter.very.very.lon

Re: [swift-evolution] History and future of Swift's parentheses

I vote language complexity in the form of hygienic macros. /me slinks away On Sat, Jun 10, 2017 at 1:25 AM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > > On Jun 9, 2017, at 2:42 PM, Gor Gyolchanyan via swift-evolution < > swift-evolution@swift.org> wrote: > > > > My a

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 2:42 PM, Gor Gyolchanyan via swift-evolution > wrote: > > My answer to `inout` is to promote it to a full-fledged "storage class" (in C > terminology) and allow normal variables to be `inout`. > This would immediately solve the problems with `inout` being a magical thing

Re: [swift-evolution] History and future of Swift's parentheses

The topic of this thread: It is simply the history and future of parentheses in Swift. My initial post is just a starting point, it could have been something else. But I'm interested to hear what people have to say about the history and future of Swift's parentheses. What is messy: As I said, many

Re: [swift-evolution] History and future of Swift's parentheses

It may make things more terrible. The solution introduces two separated type system and one is Swift 3 mode for asterisk syntax. > Robert Bennett via swift-evolution 於 2017年6月10日 > 上午6:02 寫道： > > I see. My ideal solution to this would be an explicit tuple packing and > unpacking API, as oppos

Re: [swift-evolution] History and future of Swift's parentheses

I'm confused as to the topic of this thread: On the one hand, you're starting off with a statement about parentheses being used for multiple different things, suggesting that what you want to discuss is related to spelling using parentheses. OTOH, the exercises that you put forward show that you'

Re: [swift-evolution] History and future of Swift's parentheses

The analogy of the special first parameter label was relevant (for me) in that it was a special rule that was invented to resolve a problem/situation with no clear best solution. Probably most people agree now that the current simpler and more uniform rule set for parameter labels are obviously bet

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 9:12 AM, Gor Gyolchanyan via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> >> So I wonder if any of you have had any thoughts about what Swift's >> parentheses-related future (or evolutionary baggage) will be? >> > > I really wish swift used the concep

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 2:10 PM, Jens Persson via swift-evolution > wrote: > > The point of exercise 1 is to show that it is impossible (in Swift 4) to > write a generic function composition operator (or function) which works as > expected for any reasonable functions. > This was possible in Sw

Re: [swift-evolution] History and future of Swift's parentheses

I see. My ideal solution to this would be an explicit tuple packing and unpacking API, as opposed to implicitly flexible functions. Something akin to (borrowing Python’s asterisk syntax): func compose(_ g: (*U)->*V, _ f: (*T)->*U) -> (*T)->*V {...} The asterisks indicate that the arguments to t

Re: [swift-evolution] History and future of Swift's parentheses

My answer to `inout` is to promote it to a full-fledged "storage class" (in C terminology) and allow normal variables to be `inout`. This would immediately solve the problems with `inout` being a magical thing in functions, as well as a convenient way of storing "references" (in C++ terminology)

Re: [swift-evolution] History and future of Swift's parentheses

The point of exercise 1 is to show that it is impossible (in Swift 4) to write a generic function composition operator (or function) which works as expected for any reasonable functions. This was possible in Swift 3, but in Swift 4 it will only work for functions with exactly one parameter. You'd h

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 1:17 PM, Gor Gyolchanyan via swift-evolution > wrote: > > Yes, except why would you need to define `((A, B)) -> C`?, If you need to > pass a 2-element tuple into a function that takes two parameters - you can! > If you want to pass two values into a function that *looks*

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 9, 2017, at 8:12 AM, Gor Gyolchanyan via swift-evolution > wrote: > >> >> So I wonder if any of you have had any thoughts about what Swift's >> parentheses-related future (or evolutionary baggage) will be? >> > > I really wish swift used the concept of tuples **exclusively** for al

Re: [swift-evolution] History and future of Swift's parentheses

Yes, except why would you need to define `((A, B)) -> C`?, If you need to pass a 2-element tuple into a function that takes two parameters - you can! If you want to pass two values into a function that *looks* like it takes a single 2-element tuple - you can! Seems to me that the difference bet

Re: [swift-evolution] History and future of Swift's parentheses

> Le 9 juin 2017 à 17:12, Gor Gyolchanyan via swift-evolution > a écrit : > >> >> So I wonder if any of you have had any thoughts about what Swift's >> parentheses-related future (or evolutionary baggage) will be? >> > > I really wish swift used the concept of tuples **exclusively** for all

Re: [swift-evolution] History and future of Swift's parentheses

> > So I wonder if any of you have had any thoughts about what Swift's > parentheses-related future (or evolutionary baggage) will be? > I really wish swift used the concept of tuples **exclusively** for all purposes that involve parentheses, as well as dividing tuples into two categories: - B

Re: [swift-evolution] History and future of Swift's parentheses

At first I thought that task 1 looked innocuous enough; then I discovered this bizarre behavior. Not sure if this was the point of your email.  func compose(_ g: @escaping (U)->V, _ f: @escaping (T)->U) -> (T)->V { return { x in g(f(x)) } } func strung(_ tuple: (Int, Int)) -> (String, String) {

[swift-evolution] History and future of Swift's parentheses

Swift uses parentheses for a lot of different things (tuples, parameters, calls, grouping, pattern matching, etc), this has led to some confusion, for both language designers and users. Here's a practical introduction that is possibly worth more than a thousand words (or perhaps even swift-evo pos