[EXPLICIT] Keyword return (needless_return and implicit_return)

[xavetar]

Summary

In an attempt to prohibit any implicit definitions and language constructs that do not comply with the properties of explicitness, such as return - which for some reason is usually omitted, clippy does not generate either a warning or an error.

How forbid any IMPLICIT representations of these language constructs? Why does Rust allow the use of these IMPLICIT constructs? Where did the mania for reducing everything possible come from? Why is there a keyword "allow" but not a keyword "require"?

Reproducer

lib.rs:

#![allow(clippy::needless_return)]
#![forbid(clippy::implicit_return)]

Version

Current Stable: 1.83.0

[samueltardieu]

Where did the mania for reducing everything possible come from?

You will find implicit returns in Lisp, as far as the 1960s, and in every functional language since. This may even predate Lisp.

Why is there a keyword "allow" but not a keyword "require"?

Clippy uses lint levels from the Rust compiler. Your question about lacking require would be better addressed there.

[xavetar]

You will find implicit returns in Lisp, as far as the 1960s, and in every functional language since.

Yes, but Rust is not a language with dynamic typing - it is a language with strict static typing, the task of any function (functor) is to return a result. We can't say in the context of math, let's remove = or maybe remove -, +, *, / . Why do we need them when we have the result of the expression?

Clippy has built-in keywords that allow you to disallow this behavior and use “return” directly, without IMPLICIT returns, but when you EXPLICIT disallow this behavior, no warning or error is raised.

Lisp is a high-level, non-memory-intensive language, its semantics are not similar to statically typed languages. They have very little in common with Lisp their dialects and ideologies are fundamentally different.

I understand if Rust had moved away from any currently known paradigms, then such a decision might be justified, except it doesn't. The language provides for these constructs, except that the algorithmic capabilities of clippy are not sufficiently realized to use it on a permanent basis in a stable branch, clippy is in beta release and does not have “perfect normal form” (PCNF), so the only question is, why is clippy used in a stable branch?

According to your narrative, one might conclude that Rust is a characterless entity, a sponge that absorbs other people's ideas of how code should look?

And over time Rust will turn into a bloated mutant like C++, in which entities consist not of hardware code, but of high-level code (tied to the execution environment)? In my opinion, in such a case, there is nothing normal left but C.

[y21]

Blocks are expressions and its tail expression is what the block evaluates to. If you think of a function body as being a block, then it naturally follows that the tail expression of the function body block is what the function will return.

That said, some people have different opinions and dislike it regardless of whether it makes sense from a language design point of view, and that's fine and is also why we have some of the restriction lints. I'm a bit confused about what this is requesting though. The reproducer has no code other than enabling implicit_return. Do you have a case where that lint doesn't emit a warning and you want to report a false negative?

[xavetar]

Blocks are expressions and its tail expression is what the block evaluates to.

Look, from this position, it can be considered acceptable. You can talk all you want about absolute mathematical representation of S-forms, but the user interacts with the language, not with the underlying representation. The result of this expression is machine code, which in its turn contains a return instruction. We write code in a language, the language obeys the rules of linearity, of sequential presentation. When we talk about machine representation, mathematical representation and language representation, we are talking about different entities.

That said, some people have different opinions and dislike it regardless of whether it makes sense from a language design point of view, and that's fine and is also why we have some of the restriction lints.

I have no opinions, such behavior of the language causes complete irritation (to put it mildly). The language tries to sit on several chairs, simultaneously believing that it is independent of the machine representation and at the same time being completely dependent on concepts created earlier by others, the language cannot separate these representations - it is not in its capabilities.

I'm a bit confused about what this is requesting though. The reproducer has no code other than enabling implicit_return. Do you have a case where that lint doesn't emit a warning and you want to report a false negative?

The question posed by this issue is to make it so that IMPLICIT constructs (return) CAN BE disallowed/restricted, if someone wants to write IMPLICIT code, that's their problem:

#![deny(clippy::implicit_return)] | #![forbid(clippy::implicit_return)]