Feature request: Add ability to mark closures as "Functional"

Erlang is definitely used in the industry. WhatsApp uses Erlang for their messaging servers, and Klarna, a company that according to themselves handles payment and installment plans for 35 million consumers, among those a very large part of all Swedish web stores, are well known for their reliance on Erlang. Clojure is also used quite much in the industry, but I don't have any high-profile examples.

B would have to be a functional property to be usable from A, so I suppose when D tried to override B with a non functional override the compiler would produce an error at that point.

The benefit of "pure functional" programming in this regard is that it allows you to effectively control and reason about how state can change, by eg using the type system to help you keep track of side effects. Such things/practices are often unheard of in the "classic-oop/imperative-camp" and thus lots of unnecessarily complex, hard to maintain and error prone code is written with state unwittingly scattered all over the place. Aspects of functional programming is slowly making their way into main stream programming exactly because of these advantages, see eg ReactiveCocoa and (as for Erlang not being used in the industry) have a look at the Wikipedia article about Erlang and the Companies using Erlang section.

I wouldn't mind seeing this as well. It would be a lightweight, opt-in way to ensure that your functions and closures are side effect free, which can be very useful even if you aren't consciously programming in a functional style. I'd suggest naming it @pure - it stands out, is slightly more intuitive than 'functional', and probably won't evoke the knee-jerk reactions the latter tends to do 🙂.

Just read on ReactiveCocoa - Their philosophical page... NEVER in my life have I read such insane blubbering, not even in church. State is NOT harmful. State is how reality works.

It's not like "state" is about to be banished or something. No one says we should get rid of state, people are only asking for more powerful tools for controlling and reasoning about state (like eg the programmer and the compiler being able to tell which function has side effects and which hasn't). This is useful, as is eg a powerful type system. I wouldn't argue against a better type system by saying "raw bits and machine words are NOT harmful, bits and machine words are how computers work", especially not if the better type system still would let me have access to the bits and machine words.

Technically speaking, in pure functional programming there is no mutation, and by definition, no state. While you can do pure functional programming in Swift, we are promoting what we consider to be a more general and flexible cure for most of the ills addressed by pure functional programming: instead of eliminating mutation, eliminate sharing by using value types. Immutable types (including classes) are just a special case of value types, since in Swift you can only do mutation by assignment and all effects are local (and then you can use "let" bindings to prevent assignment). Using value types gives you scalable control over mutation without the kind of hoop-jumping and inefficiency that sometimes results from being locked into total immutability. I recommend the "Building Better Value Types in Swift" talk from WWDC 2015 for more on this.

All that said, having some kind of "pure" annotation for functions, methods, and closures has some real potential benefits; I expect we'll continue to look at such features with interest.

HTH,

Dave

I think this proposal actually complements the effort to better control mutations in Swift. It is impossible to eliminate sharing by using value types as long as there are values with reference semantics (like closures!). Here's some code that showcases this:

func newCounter() -> () -> Int {
  var value = 0
  return { ++value }
}

let c = newCounter()
c()   // 1
c()   // 2
c()   // 3

This example just uses value types in combination with closures. If we would be able to distinguish closures with side-effects from closures without, we could allow the prevention of the kind of value sharing that happens in this example.