[swift-evolution] [Proposal] Tuple Extensions

I’ve been contemplating this idea for a while now, mostly because I think it’s a very important feature, but also because I can’t find a single example of a programming language getting it completely right. In Swift, the motif of tuples throughout the language would lead one to think that they

Re: [swift-evolution] Move where clause to end of declaration

Hi there, just wanted to let you know I have a name! It's unfortunate that the mailing list won't accept the update I've made (this has been the 3rd-ish time I've tried). ~Robert Widmann 2016/05/02 3:16、David Hart のメッセージ: > Hello swift-evolution, > > I took the pitch

Re: [swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

Just a quick thought, but isn't this what NSArray is for? If you know the type of a thing at runtime, it's probably best to use the part of the language that will help you most in that area: the Objective-C bridge. Doug is right that this is the shade of dependent types and would require a

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

+1. The only times I've ever had to use this outside of HoFs were dirty, dirty hacks that probably should have used this anyway. I can stomach an extra bit of syntax everywhere if it means removing an inconsistency in the wider language. ~Robert Widmann 2016/04/15 0:57、Chris Lattner via

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

Even better. +1. ~Robert Widmann 2016/04/06 14:35、Pyry Jahkola via swift-evolution <swift-evolution@swift.org> のメッセージ: >> On 06 Apr 2016, at 21:30, Developer via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> If you've ever gotten to the

[swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

If you've ever gotten to the point where you have a sufficiently generic interface to a thing and you need to constrain it, possibly in an extension, maybe for a generic free function or operator, you know what a pain the syntax can be for these kinds of operations. For example, the Swift book

Re: [swift-evolution] [Proposal] Make optional protocol methods first class citizens

To be fair, the "spirit of UIKit" that you mention comes from a time and language that encouraged OO and OO alone. Optional methods are, more often than not, backed by gigantic bit fields that keep track of whether or not the delegate actually conforms to the entirety of a protocol, which

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

+1 ~Robert Widmann 2016/03/31 10:26、Jeff Kelley via swift-evolution のメッセージ: > I have never taken advantage of this, personally. Given that there isn’t > anything that this feature enables that can’t be done if it’s removed―aside > from reordering arguments―I’d be

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

e, >>> awful, didn’t know that >>>> so in theory conversion of Int32 to Double is fine, and Int16 to Float >>>> might be as well, but I’m not certain if it’s a good idea or not, as it’s >>>> not quite the same as just extending the value. >>>

Re: [swift-evolution] Implicit Type Conversion For Numerics Where Possible.

but that is normal in a floating point domain; E.g. also with: > var v:Double = 1.0 // Double to Double > > v would have the same imprecision… and could be anywhere between > .9998…1.1 > (rough estimation, depending on magnitude and the floating point

Re: [swift-evolution] [Review] SE-0048: Generic Type Aliases

What is your evaluation of the proposal? +1. Especially for forcing the alias side of the declaration to explicitly keep track of type constraints. Is the problem being addressed significant enough to warrant a change to Swift? Yes. Previously, one could "work around" this by declaring a 0-case

Re: [swift-evolution] Keyword Discoverability

Give escape a whack sometime. ~Robert Widmann 2016/01/04 3:43、John Joyce via swift-evolution のメッセージ: > Hello all > > It feels like Swift has some risk of going the direction of C++ at times. By > that I mean complexity creep. > Increasingly nuanced scoping

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

Well, that's just it. $ is a perfectly valid character in identifiers everywhere but in the grammar for operators for some reason. It isn't reserved, it just isn't there. ~Robert Widmann 2016/01/03 0:53、Brent Royal-Gordon のメッセージ: >> Swift currently does not allow

Re: [swift-evolution] Better syntax for deferred?

-1. `defer` doesn’t exist just to execute code at the end of blocks, it exists to allow resource cleanup when you have a function with multiple return points or non-trivial scoping. For example, let’s add an if statement to your code: func clear() { print("1") print("3") if

[swift-evolution] [Proposal]: Free the '$' Symbol!

Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

That doesn't look like a variance issue to me, that's about the same "information" invariant I talked about before. The former works because self resolves to an invariant type, the type of the implementing structure, which satisfies the requirement Self introduces. The latter does not because

Re: [swift-evolution] Self behaves inconsistently in protocol method signatures

My understanding of Self is that it is a special generic parameter resolved by the type system to the type of the implementing structure. That resolution must be invariant because the implementing structure (here, non-final classes) can choose to yank the protocol's invariants out from under

Re: [swift-evolution] Beef up Imports

Pyry Jahkola via swift-evolution > <swift-evolution@swift.org> wrote: >>> On 27 Dec 2015, at 07:12, Developer via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> Therefore, I propose the introduction of 3 agda-esque operation

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] 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

rds are equal, are different languages around the world, with > different keyboard layouts. However in all I can type "in" but not this > symbol that can only reproduce by copying and pasting. > > >> Em dom, 27 de dez de 2015 às 21:58, Developer via swift-evoluti

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