I'd like to eliminate all identifiers. They make languages boring.
It isn't a good idea to make your own when everyone else knows and expect to be reading standard code.
There are a few characters you can trim.
let len = if text.starts_with(s) { s.len() } else { None? };
Or functional. (not a fan.)
let len = Some(s.len()).filter(|_| text.starts_with(s))?;
I think semantically an ? should be thought of as an unwrap, and I don't think using it on bools corresponds to an unwrap at all, which is why I don't like it.
A agree. I don't understand the modern obsession with doing away with the age old structured programming "if', "then", "else", "while", etc.and squishing everything down to the shortest possible one liner using obscure replacement words for those things.
I'm not sold on the idea that brevity aids clarity and expressiveness,
Is there actually any practical benefit to all this?
I mean, the if in question might be similar to an if used for error handling, which is probably why it is compared to go, but we aren't actually handling an error here.
Coupling it to the len call semantically says the length might fail, but it would also be valid to put the check on some other variable without changing the behavior.
This is not a failure arising from computing the length, so the error shouldn't be thrown from the length computation.
I cannot fathom why anybody would want to spell "if" as "ternary!" or "filter" and then hide the control flow in a function call. What is the reason for desiring this obscurity?
It saves you having to write redundant code. For example, the "?" operator is normally used in functions that return Option or Result. You can write in a single line a "trivial and common" concept. I like it
As always, things are judgement calls. One could even consider if itself an "obscure replacement word" for match { true => ..., false => ... }, at some level.
When does something become well-known enough to avoid such feelings? I don't know. Write the code however you (and your project's coding conventions) think is best.
All of programming is nothing but "sequence, selection and iteration". Since my first introduction to programming with BASIC in 1974 that was done with "if" and "for" and similar constructs. Having used ALGOL, PL/M, Ada, Pascal, Lucol, C, C++, Java, Javascript, and more since then Rust is the first language I have seen that had the conceptually more complex "match".
However "match" not what I'm questioning here. Nobody had mentioned "match" until you did.
I'd like to rephrase the intent of ohenley's, now flagged, post above in a less strident way. Using the words of Python creator Guido van Rossum on his retirement today:
'Dropbox said van Rossum has had a major impact on its engineering culture. "There was a small number of really smart, really young coders who produced a lot of very clever code that only they could understand," said van Rossum. "That is probably the right attitude to have when you're a really small startup." However, as Dropbox notes, when the company grew, new engineers could not understand the clever but 'short and cryptic' code written by and for earlier developers. Van Rossum called this "cowboy coding culture" and educated the company about the value of maintainable code. "When asked, I would give people my opinion that maintainable code is more important than clever code," he said.'
I do hope nobody here feels the need to red flag the words of Guido.
Newbie here but I found myself writing something like
let bar = match foo {
true => "do the thing",
false => "no don't",
};
and then got embarrassed because if is probably more appropriate here. Just infatuated with pattern matching I guess
The (apparently, by consensus-ish?) idiomatic version:
if !text.starts_with(s) {
return None;
}
let len = s.len();
makes the fact that this is returningNoneearly very clear. Which for a beginner like me was particularly unclear in OP's solutions. I though None was being assigned to len, which I think is an easy mistake to make.