Re: [swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

Hi everyone, I read every post in the Higher-Kinded Types ( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html ) thread from about a year ago, and I was wondering what's the

Re: [swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

Hi Chris, thanks a lot for the answer, that's exactly what I wanted to read and it gives me hope for the language's future :) - Elviro > Il giorno 12 dic 2016, alle ore 06:46, Chris Lattner <clatt...@apple.com> ha > scritto: > > On Dec 11, 2016, at 5:48 AM, Elviro Rocca v

Re: [swift-evolution] [Idea] Custom keywords for operators.

I understand the technical problem here, and killed my hope for "nominal" operators long time ago with fire. But if someone here uses Kotlin, they know very well how great it is to be able to infix functions of 2 parameters like they were operators: it makes code extremely clean and readable,

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Wrapper structs FTW. I think it's a lovely pattern that's super Swifty and really should be advertised more for solving these kinds of problems. Language-level features could also be useful for making that more usable, and the discussion about "strong" typealiases seems oriented in that

Re: [swift-evolution] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Huge +1 This should have been there from Swift 1, and basically forced me to use Sourcery to automatically generate all that code. Elviro > Il giorno 10 ago 2017, alle ore 01:09, Chris Lattner via swift-evolution > ha scritto: > > Hello Swift community, > > The

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Subscripts in Swift in fact have always looked to me like a way to make objects "callable", where you use brackets instead of parentheses: the difference of course is the fact that, when used point-free, the object will be considered an instance and not a function. In this sense we could

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

Overloads are ugly. The very existence of an overloaded function usually means a lack of available abstractions, or an insufficient abstraction power in the language: exhibit A is conditional conformances to protocols. Overloads are particularly ugly if the overloaded function's input

Re: [swift-evolution] [Pitch] Guard/Catch

s when I'm binding the result of a throwing function (which in fact is isomorphic to a Either<T,Error>) and binding an Optional. Elviro > Il giorno 10 lug 2017, alle ore 10:44, David Hart <davidh...@fastmail.com> ha > scritto: > >> >> On 10 Jul 2017, at 0

Re: [swift-evolution] [Pitch] Guard/Catch

} > > guard let x:X = try? X() else { > print( "Things failed ") > return > } > > x.foo() > } > > f()// works > ``` > > Having to call a throwing, Void method before performing the rest of a > function seems like an edge

Re: [swift-evolution] [Pitch] Guard/Catch

This is not a sugar proposal, in the same way as "guard" is not syntactic sugar, because it requires exiting the scope on the else branch, adding expressive power and safety to the call: also, the sugary part is pretty important because it avoids nested parentheses and very clearly states that

Re: [swift-evolution] [Pitch] Guard/Catch

Amazing proposal, I love it and thinking back there's plenty of times where I would have used the guard-catch instead of the non-swifty (to me) do-catch. A guard-catch construct still allows to handle errors explicitly, with the added convenience of forcing a return inside the catch, which is

Re: [swift-evolution] [Pitch] Small bit of sugar for enum case with Void associated value

+1 to this I not only support the case in question, but I 100% support any proposal that would push to compiler to completely remove any distinction from isomorphic tuples, by always reducing the tuple to the simplest form (this kind of discussion also took place in the thread about the SE110

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

Even if ?? is generally assumed as safe, fatalError would be there to clearly assert what's going on. This is true in general for fatalError, which presence in some code simply means that something could go wrong there, so the regular compilation-level safety cannot be a given. And as forced

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

100% agree with everything. A custom operator is a good idea for operations that are actually frequent: once you learn what it means, it really helps reduce noise in code and improve readability. But forced unwrapping is something that's intended to be used sparsely. Elviro > Il giorno 30

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution > ha scritto: > > Finally, there’s a woolier justification: there’s an often-touted > misconception out there that force unwraps are bad, that they were only > created to accommodate legacy

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

e practices that in my opinion should not be encouraged. Elviro > Il giorno 29 giu 2017, alle ore 12:12, David Hart <da...@hartbit.com> ha > scritto: > > > > On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution > <swift-evolution@swift.org <mailto:swift-

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> Well, a persisted inconsistency is worse than a crash :P I still strongly disagree with this, I'm sorry. Inconsistent data is an orthogonal problem to fatal errors, and a crash is basically a middle finger to the user. > To me this !! operator does not add enough value to put it in the

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

Covariant generic types make for an unsound type system. I believe the reason why Array and Optional are covariant in their generic parameter is that the way their implementation interacts with their internal storage assures that new storage is created if types mismatch: this means that to make

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

I agree with everything you wrote, in particular I agree with the idea that it is more important to get the big efforts right, and that they should take priority. But I would consider a distinction: - big efforts that add huge new features to the language so that things that were done in

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

I read many times the "most users don't care about this" objection but I always considered it more like an argument for postponing something than removing it completely from the Swift equation (I believe I also read words like that from yourself, Chris), because there is a point about

Re: [swift-evolution] [Concurrency] async/await + actors

I'm also available to help on the topic of pure functions, if you need any :) Elviro > I suggested a little while ago on this list some principles based on this > that would allow for the compiler to enforce value semantics with a `pure` > attribute and I'm currently working on a draft

Re: [swift-evolution] [Concurrency] async/await + actors

Thanks a lot for this piece: it was a great read, that could serve as primer to most discussions about async programming in general, also thanks to the various links and references. Here's my thoughts: - You might have been too soft on the callback-based syntax of many Cocoa APIs: those are

Re: [swift-evolution] Revisiting SE-0110

Hi, thanks for the answer. >> …by showing code that’s marginally different from each other, like one more >> nesting of parentheses, or one less label for a parameter. It seems to me >> that distinctions like these are just important at the compiler level, but >> not particularly useful from

Re: [swift-evolution] Revisiting SE-0110

This has been a very hard discussion to follow, even for a programmer that mostly just silently reads these threads to get a general understanding of what's going on in the community. There's an overwhelming amount of messages that point out potential bugs and unexpected behavior by showing

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

Yep, "logic" failures are not supposed to be there if not for avoiding checks that could worsen performance in pieces of code that should run as fast as possible. I like Adrian's solution because it doesn't add a new operator to the standard library, something that could mean one more

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

Huge +1 Calling "flatMap" a map + filtering out the nil values was a TERRIBLE idea. Elviro > Il giorno 24 ott 2017, alle ore 00:15, Max Moiseev via swift-evolution > ha scritto: > > Hi swift-evolution! > > I would like to propose the following change to the

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

"Flattening" in the context of functional programming (and that's where map and flatMap come from) means something like this: F -> F So for example: Array -> Array or Optional -> Optional but NOT: Array -> Array It's simply the wrong word for the operation.

Re: [swift-evolution] Optional Argument Chaining

While it's definitely worth knowing, it's not a really usable substitute for higher-kinded types in production code, and still requires a lot of code generation, which is eased in Kotlin thanks to its annotation/metaprogramming features. Event the Kategory people recognized that the emulation