from a language design perspective the ubiquitous overloading of . to mean both field access and method calls is soooo frustrating
-
-
Replying to @glaebhoerl
what are you talking about, accessing a field is just calling a getter/setter!
1 reply 0 retweets 0 likes -
Replying to @Gankra_ @glaebhoerl
alt: what are you talking about, calling a method is just getting the `method` field, and then calling the value stored there!
1 reply 0 retweets 0 likes -
Replying to @Gankra_
see that's precisely it. calling a function that's in a struct, and calling a function in the environment with the struct as arg ...
1 reply 0 retweets 0 likes -
Replying to @glaebhoerl
... are not _at all_ the same thing. but it is completely entrenched that everyone expects both of them to use .
2 replies 0 retweets 0 likes -
Replying to @glaebhoerl
what, your languages don't implement methods as functions which have curried `self`?
1 reply 0 retweets 0 likes -
Replying to @Gankra_
I mainly just want `a.f(b)` (using dot syntax for purpose of demonstration) to be sugar for `f(a, b)`
3 replies 0 retweets 0 likes -
Replying to @glaebhoerl
Type-dependent resolution is what makes methods usable in Rust. What's your solution for that?
1 reply 0 retweets 0 likes -
Replying to @eddyb_r
some kind of type-directed name resolution is indeed one way, type-based ambiguity resolution plus glob imports is another
2 replies 0 retweets 0 likes
C++ does that (ADL) and it’s confusing. IMO it’s not worth complicating all name lookup for aesthetic reasons.
-
-
Why assume I want to do the same thing as C++? Like, "type-directed name resolution" describes both C++ and Rust
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.