Besides, imagine a world of Java, Javascript, C-like anything, where you would be DISALLOWED to have a semicolon after the last statement in a block. Crazy thought, right?
Besides, imagine a world of Java, Javascript, C-like anything, where you would be DISALLOWED to have a semicolon after the last statement in a block. Crazy thought, right?
Groups frequently make collective decisions through majority rule. Legislators pass bills by majority; shareholders make most corporate decisions by (share-weighted) majority rule, as do directors; clubs, university faculties, and civic associations typically use majority rule as well. The reason that they do so is not entirely clear. (Emphasis mine).
Not clear? It's almost too clear as to be tautological.
They do because they (a) think all members should have equal say, (b) most members in the group want X to be done.
Unless we're talking about submitting to force or listening to expertise, why would many people wanting to do something, let fewer people tell them what to do instead?
Heck, if it comes to fighting for what's to be done (the most effective but primitive form of getting a decision), the majority could beat up the minority and have its way anyway.
I upvoted you for your link, but actually the argument that it would be good because people who care more will make a better decision than those who don't does not completely convince me. Someone could care a lot about something but still have the wrong idea about it.
What I imagine QV does is find the point at which participants who don't care so much would rather pocket the funds and walk away, rather than spend it on voting.
If the ballot measure is "Eat Vinnl", you might want to spend a lot to vote it down, but it might not take much to convince the others not to spend it back at you (and you all eat berries instead). If the ballot measure is "Vinnl eats everyone else", you won't be able to spend enough that everyone else can't just spend it back at you, more efficiently.
Edit: one important difference here is that unless the GP is actually going to pony up real money, something of value to those they inconvenience with their (imo silly) opinion, it doesn't make much sense.
Anyway, I see it's been submitted separately :) https://news.ycombinator.com/item?id=15206291
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;
}
and now with one implementation I can deal both with functions that return meaningful values, and "computations" that do some work but return nothing (other than `()`).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"
};
If you add semicolumns after the strings the `if` will always evaluate to nil here.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
}
or: list.sort_by(|a, b| a.key < b.key);
This way you focus on what's important.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.
I just think that using the semicolon to make the function return unit instead is problematic. It would be better to have the type system guide that decision, like in Scala. It would be even better to have an explicit `ignore` function or something (like in OCaml) to signal to the compiler that you really want to ignore the value and you only care about uthe side effect. I mean, why would you ever write just e.g. `a < b;`?
Agree. The idea to attach additional semantics to ; is completely nuts, especially as ; is mandatory in Rust (usually, there are odd corner cases where it is not allowed).
Just get rid of mandatory ; completely and let the type system handle the rest.
I guess you could use significant newlines like python but I never really liked that. I think Rust's compromise is pretty decent.
In particular it's the first time I hear people complaining about it, so far most users (myself included) seem to be praising it. Javascript's handling of semicolon is nuts, I wouldn't say Rust's is.
We have computers they are perfectly able infer them for me.
> Javascript's handling of semicolon is nuts, I wouldn't say Rust's is.
- JavaScript does insane things, as usual. This doesn't mean every implementation of semicolon inference has to be that bad and broken.
- Rust goes the other way by pretending it's still 1990.
There are plenty of languages out there that handle semicolon inference perfectly fine.
(Heck, I even let the IDE show me where the compiler has placed them.)
it just makes obvious that "result of something" and "control flow back to caller" are very different things.
function square(const x : Integer) : Integer;
begin
result := x * x;
end;
Is equivalent to: function square(const x : Integer) : Integer;
begin
result := x * x
end;
If you mean in if-then-else constructions, then yes the semicolon must be at the end of the statement: if (condition) then
dosomething
else
dosomethingelse;(I'm ignoring the comma operator, which is a special case and not relevant to the main point.)
foo(x, -y)
is not the same as foo(x -y)
(from your last sentence, I assume you were talking about JS in general, not just JSON)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.
Does use commas for lists and tuples, though. The latter kind-of make sense, it's the commas that identify the expression as a tuple. Not sure what the rationale for commas in lists is, though.
[1] Slightly complicated by currying (arguably, it's several successive function applications rather than one multi-arg application) but the end result is the same...
Well, you need some separator, and spaces won't do since [x y] has x applied to y.
Although could, in principle, make space-between-list-items higher precedence than function application. E.g.:
[x (func y) z] res = -x ==> negative x
res = c - x ==> c minus x
res = - x ==> syntax error foo(x -y) => foo(x, -y)
foo(x - y) => foo(x - y)https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
(1) where nobody = limit(somebody) -> 0