[Xeamek]

There are restrictions out on You by the borrow checker to ensure safety, and then there are restrictions put on You by rust design team 'just because'.

Again, the former are fine, it's the latter I have a problem with.

[pdimitar]

In order for me to agree on the "just because" part you'll have to give some examples. What made you think they are arbitrary? And how did they prevent you from doing your job?

[Xeamek]

Comment above, mentioned borrowing while structs instead of borrowing memory. I believe this was once discussed under term 'partial borrows', but the "idiomatic" aproach is to 'just split your structs'.

Which isn't really a good aproach to structuring codebase, it's just to appeal to borrow checker inflexibility.

Lack of global scope. Lack of function overloading.

[Measter]

> Comment above, mentioned borrowing while structs instead of borrowing memory. I believe this was once discussed under term 'partial borrows', but the "idiomatic" aproach is to 'just split your structs'.

You're mistaking "idomatic because it's the only way" with "idomatic because we say say so". There is currently no way in Rust to specify the granularity of a borrow, so we're stuck with splitting your structs to get around it.

Part of the problem is that it's a hard problem to design around. It can not be done automatically by the compiler, because it would result in changes in the implementation being changes in the type signature. For example, say we have this function:

    pub fn foo(&self) -> i32 {
        self.a + 5
    }

The granularity is borrowing `a`. If we then change it to this:

    pub fn foo(&self) -> i32 {
        self.a + self.b
    }

The granularity of the borrow has changed in a backwards incompatible way (it now includes `b`), but that change is not reflected in the signature. It's the same reason why the compiler refuses to infer signature lifetimes from function bodies now.

You could, of course, say that we can allow the programmer to specify it manually:

    pub fn foo<'borrow>(&'borrow self) -> i32
        where 'borrow: 'self.a + 'self.b
    {
        self.a + self.b
    }

But this is now leaking implementation details if `a` or `b` are private fields.

[Xeamek]

That's truism, ofcourse there is no way to do something that is not impemented.

The question is whether or not the fact of it not being implemented comes from problem difficulty, or designers explicit refusal to do so

[aw1621107]

> Lack of function overloading.

Isn't there at least some technical basis for this (less-than-ideal interactions with type inference IIRC)?