anton

Don't believe them, there is more great and some frustrating stuff afterwards.

How dare @Feyd@programming.dev not reveal the address of the programmer instance.

Doesn't like puritan cultural influence, left.

* Swedish developer of the year

Don't get me wrong, he does great work, but your post should mention it somewhere.

Rust doesn't allow type inference in function signatures, c++ does with auto. IIRC, they recommended against using it, because of -you guessed it- compile time.

I know, but otherwise there is no use for the knowledge that we live in a simulation. Unless someone can contact the outside of course.

The only thing one could do with knowledge of being in a simulation, is trying to find bugs and exploits.
From now on, I expect anyone claiming we live in a simulation to have a working perpetual motion device, faster that light communication, or something similarly impressive. If they don't, their claim is ~~meaningless~~ useless.

But you’re also missing one use of the impl keyword: fn func() -> impl Trait.

[...] So dropping the impl in [return position] might not be completely impossible like the other uses of impl.

But the impl markes that it is a trait to the programmers.
Take the following functions:

func1()->A{...}
func2()->A{...}

Does the following snippet compile?

let mut thing = func1();
thing = func2();

Under the current rules we know it will. But if A could be a trait, the functions could return different types. We currently mark that with the impl.

Why? What value does -> () provide? Why not elide that?

What value is provided by keeping it?

What value does cluttering up your code with -> () provide?

Why a syntactic special-case for exactly that type and not any other random type?

Because the unit type is special, just like the never ! type. () also has the special importance of being the return value of an empty statement and some other stuff.

languages w/o [semicolons] feel awkward since you’re generally limited to one statement per line

Then fixing that might make sense. :-)

It's fixed with semicolons ;-)

I'm sorry I don't know all the arcane incantations of your court system of the top of my head.

If the spec contains default values why not make a constructor with all the missing fields or implement Default when all fields are covered?

Also lol:

#[test]
fn test_config_load() {
    todo!();
}

And considering the content of the "comics", one set up to glorify AGI as our lord and savior.