Made with KolourPaint and screenshots from Kate (with the GitHub theme).

  • marcos@lemmy.world
    582·
    20 hours ago

    Good, now invent a keyword for variables you don’t want to declare the type. And now that you have a mix of keywords and identifiers on the same place, you can never update your language again.

    Also, make the function declarations not use a keyword too, so you get the full C-style madness of code that changes meaning depending on what libraries you import.

    • ZILtoid1991@lemmy.world
      3·
      10 hours ago

      Good, now invent a keyword for variables you don’t want to declare the type.

      auto. Also in D, you only need const if you don’t want to specify a type for a constant, the compiler automatically inferres it to you.

      Function declarations can be easily decyphered from context, no problem.

    • stingpie@lemmy.world
      15·
      18 hours ago

      I don’t understand how not using a keyword to define a function causes the meaning to change depending on imports. I’ve never run into an issue like that before. Can you give an example?

      • marcos@lemmy.world
        6·
        17 hours ago

        Some declarations terminate on the name, other declarations go one requiring more tokens. In C, the only thing that differentiates them is the type.

        Parenthesis in particular are completely ambiguous. But asterisks and square brackets also create problems.

          • sushibowl@feddit.nl
            4·
            9 hours ago

            The basic problem is that identifiers can be either types or variables, and without a keyword letting you know what kind of statement you’re dealing with, there’s no way of knowing without a complete identifier table. For example, what does this mean:

            foo * bar;

            If foo is a type, that is a pointer declaration. But if it’s a variable, that’s a multiplication expression. Here’s another simple one:

            foo(bar);

            Depending on how foo is defined, that could be a function call or a declaration of a variable bar of type foo, with some meaningless parentheses thrown in.

            When you mix things together it gets even more crazy. Check this example from this article:

            foo(*bar)();

            Is bar a pointer to a function returning foo, or is foo a function that takes a bar and returns a function pointer?

            let and fn keywords solve a lot of these ambiguity problems because they let the parser know what kind of statement it’s looking at, so it can know whether identifiers in certain positions refer to types or variables. That makes parsing easier to write and helps give nicer error messages.

            • BehindTheBarrier@programming.dev
              1·
              4 hours ago

              I feel this is related, and hightlight this even further, look at all the ways to initialize something in C++.

              https://www.youtube.com/watch?v=7DTlWPgX6zs

              If you are really lazy, have a look at making an int at around 7:20. It’s not horrible that alone, but it does show how many meanings each thing has with very little difference, added on top of years of legacy compatability accumulation. Then it further goes into detail about the auto use, and how parantheses, bracket, squiggly bracket all can be used and help with the mess.

    • piccolo@sh.itjust.works
      91·
      19 hours ago

      In C#, you can use ‘var’ to have an impilict type variable.

      String name = “”

      var name = “”

        • sus@programming.dev
          16·
          18 hours ago

          So I think it’s still probably unclear to people why “mix of keywords and identifiers” is bad: it means any new keyword could break backwards compatibility because someone could have already named a type the same thing as that new keyword.

          This syntax puts type identifiers in the very prominent position of “generic fresh statement after semicolon or newline”

          …though I’ve spent like 10 minutes thinking about this and now it’s again not making sense to me. Isn’t the very common plain “already_existing_variable = 5” also causing the same problem? We’d have to go back to cobol style “SET foo = 5” for everything to actually make it not an issue

          • AnotherPenguin@programming.devEnglish
            3·
            15 hours ago

            At least in C#, you can define variables with keyword names like this:

            var @struct = “abc”

            I think in Kotlin you can do the same, and even include spaces with backticks like val abstract class = “abc”

            I’m not sure if other languages allow that, regardless it should be rarely used.

            • pivot_root@lemmy.world
              3·
              14 hours ago

              Swift also uses backticks and Rust has a dumb one in the form of r#thekeyword. Still much better than introducing a async as a new keyword in a minor version of a language and breaking a bunch of libraries.

          • piccolo@sh.itjust.works
            3·
            18 hours ago

            Ah I was misunderstanding the problem. And learned something new about C#, seems in order to avoid breaking existing code they introduce “contextual keywords” var being added later, it is a contextual. You can create a class ‘var’ and the compiler will prefer it.