Add 👍 and 👎 for constructing ranges

[ararslan]

When people don't code quote their ranges, markdown will render a specified step size as 👍 or 👎. It does what you want, so why not make it syntax? This PR adds 👍 for a range with positive unit step size and 👎 for a range with negative unit step size.

[matbesancon]

I love it, finally a syntax proposal that will help beginners

[mkitti]

This will make Julia easier to use for emoji oriented users, opening Julia to a new generation.

[Wikunia]

Why not add 📈 and 📉 for randomly increasing and decreasing ranges?

[StefanKarpinski]

Even though this is a joke (I think I can give that away now that it's April 2nd), I can't see much actual harm in doing it. You can still use 👍 and 👎 as identifiers if you want to, they just also parse as infix operators like the word in. It also doesn't prevent them from being used in longer identifiers, just as in being an infix operator doesn't prevent sin or int from being identifiers. So: cute easter egg? Plus kind of a fun range syntax?

[simeonschaub]

Would be slightly breaking for identifiers containing 👍, but looks like we're fine on that front: https://juliahub.com/ui/RepoSearch?q=%F0%9F%91%8D&r=true

[StefanKarpinski]

Would be slightly breaking for identifiers containing 👍

Why? I haven't looked it this PR currently breaks that but it's perfectly possible to allow 👍 in identifiers but make 👍 by itself an infix operator. (This is why I used in as my point of comparison.)

[simeonschaub]

We don't require whitespace around operators, so a👍b is currently a valid identifier, while it would parse as 👍(a, b) with this PR.

[ararslan]

I should note that space is required around 👍 and 👎 with this PR, since otherwise 1👍2 parses as 1 * 👍2.

We don't require whitespace around operators

Not entirely true: 1in2 also parses as 1 * in2.

[simeonschaub]

Ah, sorry, I didn't read the PR closely enough then

[JeffBezanson]

Closing as "surprisingly plausible, but still a bit ... much".