A modest proposal (happyassassin.net)

Never mind.

Actually, let's double down: Instead of writing 1+2, you should really be writing +(1 2). Don't you see how much easier that would make things? A single, uniform syntax everywhere! + is just a function that gets called like anything else! Your foo(x -y) example would become foo(x -(y)).

I'm mostly joking.

  foo(x -y) => foo(x, -y)

  foo(x - y) => foo(x - y)

[0] http://ericposner.com/quadratic-voting/

This makes it easier to write and use generic code for which you don't know the return type (could be `String`, could be `()`), without insisting on special cases for "returns a thing" and "doesn't".

Example: I hold a thing of type `T` and want to let you call a function on it. I can write this generically as

    pub trait WithMut<T> {
      fn with_mut<R, F: Fn(&mut T)->R>(&mut self, func: F) -> R;
    }

An other reason it works is that almost everything is an expression in Rust, including things like `if` statements. So for instance you can write:

    let message =
        if auth_ok() {
            "success"
        } else if tries < 3 {
            "try again"
        } else {
            "failure"
        };

Note that this won't work if one branch returns string an and other returns an integer for instance since the type of "message" must be known at compile time.

It also works well for getter functions and lambdas, for instance:

    fn is_empty(&self) -> bool {
        self.len == 0
    }

    list.sort_by(|a, b| a.key < b.key);

I can see where you're coming from though, it's easy to dismiss this feature as a bad idea on paper, especially if you've been traumatized with Javascript's insane handling of semicolumns. In practice however it's a rather useful sugar and so far it's been harmless in my experience. It basically makes the language more lispy.

it just makes obvious that "result of something" and "control flow back to caller" are very different things.

Yes, I think they do.

The author just borrowed the title of Swift's article in the sense "here's a fun title based on a historical reference, for something that, for once, it's indeed a modest proposal".

They didn't intend it in the exact same way Swift intended it.

TLDR: Basically, in a typical Crockford move, he saw people were using them in a specific way he did not like (to store parsing parameters), so he removed them entirely. I say "typical Crockford" because some of his JS linting rules are gratuitous overkill in my opinion. He also suggests that if you want comments, you should pipe the config file through a minifier that removes them before parsing.

Doesn't seem like that much of a good reason to me, but whatever.

1. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

(ETA: JSON already has problems with canonicalization. Adding comments makes this worse. Are they in or out of the equivalence over JSON terms?)

It's also kind of messy when you have a lot of multiline strings.

Things can change. Push the world forward. Think of little things you can do that make the world of development the world you want to be in.

TBH, common JSON implementations have their problems too. Integer size and integer/float (de-)serialization tend to be somewhat interesting at times. I've even seen implementations serializing JavaScript objects as JSON (e.g., {foo: 2} instead of {"foo": 2})

JSON doesn't have "integers" and "floats", it has "numbers" which are are expressed in decimal scientific notation. There's no guarantee an implementation will let you distinguish what was parsed, and the numerical precision and range of interoperable JSON is undefined.

The bottom line is JSON is a risky proposition for financial or scientific data exchange.

And before you say JSON numbers are de-facto IEEE754 doubles, bare in mind that most JSON implementations can't roundtrip them properly.[0] A symptom of everybody wanting to write a toy implementation.

[0] https://rawgit.com/miloyip/nativejson-benchmark/master/sampl...

That's a personal opinion -- like a mild OCD annoyance, etc, most like borne just out of being used to not having them from the start.

Their benefits on the other hand (uniform syntax, easier insertions/deletions, better for source code control, etc) are objective.

And there's no objective visual annoyance when looking at the code to see that it's uniformly comma-ed.

Had braces been used, the error might have been easier to spot or might not have happened at all.