Language Design: Annotations Obsolete Modifiers (soc.me)
from soc@programming.dev to programming@programming.dev on 19 Apr 22:34
https://programming.dev/post/49088131

#programming

threaded - newest

sidelove@lemmy.world on 20 Apr 00:50 collapse

Hmm, I mean I totally understand the overlap in functionality. Especially when you get into the Java Lombok situation where annotations are as structural as the modifiers themselves. But there are clear cases in things like Python and Rust where the modifiers are a clear meta-programming that are mostly outside the scope of the language itself.

Granted, Rust is a weird example where annotations tend to “graduate” to the language itself, like in the form of #[async], but that clear delineation of what’s in the language itself and what’s defined as post-processing still leaves it more readable than if we heaped a chunk of similar-looking-but-willdy-different-effect-wise tokens on top of our function/type definition. E.g.,

#[cfg(target_os = "windows")]
#[pub] #[async] fn some_func() {
    #[mut] let my_var = 3u2;
    // ...

Vs.

#[cfg(target_os = "windows")]
pub async fn some_func() {
    let mut my_var = 3u2;
    // ...

Like, I do get the similarity in function, but it’s almost like why we have capitalization in our natural languages. Making language-defined features “louder” and more ingrained in the language itself makes sense, even if the border is fuzzy.

Edit: even going the other direction, and we do:

pub cfg(target_os = "windows") async fn some_func() {
    let mut my_var = 3u2;
    // ...

That homogenization is still a bit of a bitch to read