At it's purest, functional programming is about defining a set of data types, devoid of behaviour, and then defining a set of "free" functions over those data types, which can be freely extended as need arises. This usually comes with some sort of namespace/module mechanism, so despite the fact that the functions are free, they're not global in the sense that there's a single namespace for everything (note: I know next to nothing about Swift, so if it doesn't have a namespacing mechanism for free functions and if they indeed fall into a global namespace, then I would say it's something to be discouraged, and find the language lacking in that regard).
Now, assuming you have namespaces, is it a good idea? I suppose it's good enough, since it works for many people (and they will usually claim it works better than the alternative). It's a good way to model things in general, and it's usually a better way to model abstract concepts that would feel forced being squeezed into OO class hierarchies. That said, it has its shortcomings as illustrated by the expression problem, where FP falls squarely on the "easy to add functions, hard to add cases" side. Not coincidentally, this means that many things that are dos in FP are dont's in OO, and vice versa.
That's why the recent hybrid OO/FP languages, Swift one of them, are set on claiming some sort of middle ground between the two. But where this middle ground is, and what's just Haskell/Java written in another language will vary on a case by case basis.
Reactive Cocoa
but in RAC 3.0 all of the signal operators are not tied to the RACSignal or RACSignal classes but instead are free global curried functions.