Re: [RFC]

On Thu, Feb 13, 2020, at 2:12 PM, Mike Schinkel wrote: > > On Feb 13, 2020, at 1:48 PM, Larry Garfield <larry@garfieldtech.com> wrote: > >> But since I seem to be in the minority of caring about the name, let me > >> propose the following which was influenced by Larry Garfield's most > >> recent post. Since it seems that people want the convenience of a > >> short notation to get a closure, how about this: > >> > >> function foo{} > >> > >> foo::function — Returns name of function > >> foo::fn — Returns closure for function > >> > >> Since using fn creates anonymous function closures it > >> kinda makes > >> sense that ::fn would return a closure. > >> > >> -Mike > > > > thinking-face-emoji.gif. I could be convinced of that. It seems like "both" is > > a possible solution, but my concern would be someone using one of them in a case where either works, > > inadvertently, when the callee is expecting just one. Eg, getting into the habit of using foo::fn, > > and then using it on a builder routine that chokes "later" when it tries to serialize > > something. > > True. > > But it would be a really high bar to say we can only add new features > if we can completely protect the developer from themselves. At some > point we have to assume programmers are adults, or at least can take > responsibility for learning how the language works. Strawman argument. Nothing can "completely" protect developers from themselves; not even Rust. :-) But features should still be designed in such a way as to be hard to screw up. Not impossible, hard. The question I pose is whether "both" would be "hard enough" to get wrong that it's not going to cause more confusion than it solves. I don't know the answer to that question. --Larry Garfield