Extending tokens; scoping characters

Am I correct in understanding that the "turbofish" notation exists to avoid a parsing ambiguity?

What if Rust would accept some extended characters for certain tokens? There are a few other brackets to choose from. Like a dedicated "Generic parameter" bracket: Foo⧼Bar⧽

1 Like

As a proposal for extending the language, this belongs on IRLO, not URLO.

1 Like

I floated the same idea before, slightly tongue-in-cheek. Of the options, I'd vote for guillemets («...») as the most commonly available symbol on non-English keyboards (as far as I know).

That said, I'm not really in favor of the idea, because I don't see the turbofish notation as a problem to be solved, but that's probably a discussion to be had on IRLO.


Also: please let's not introduce symbols that can not be readily typed on an English keyboard (which is what most people use for programming). Generics are so widespread in Rust that having to copy-paste (or type in the Unicode code point of) these exotic brackets would be wildly annoying and counterproductive.


I mostly agree, but there are workarounds. Like making ::< an editor shortcut for « (with some matching shortcut for »). Also, rustfmt could be made to always emit the disambiguated brackets, so you could write Rust as you do now and fix it up post facto. A smart IDE could do that as you type. (Of course, such an IDE could instead just render ::<...> as «...», which would require no language changes.)

I'm not saying we should do this, just that I wouldn't see it as a showstopper. The bigger question here is whether the turbofish is a problem at all (as I mentioned, I don't feel it is).


Of course, but wasn't the entire point of the proposal that one wouldn't actually need to type ::< anymore?

1 Like

It was just a reflection that it's sad if a language which uses Unicode for source inputs has to introduce a syntax to work around an ambiguity due to the lack of unique braces, when there are lots of unused braces in Unicode.

With that said, I made the mistake of forgetting that most people probably don't use multiple keyboard layouts. To me it's second nature to add a new keyboard layout that is more optimized for a specific task. I never even considered "copy-paste (or type in the Unicode code point of)", which would - indeed - be very annoying.

1 Like

If you add a new type of bracket, isn't that also "introducing syntax to work around an ambiguity"? What makes « better than ::<?

1 Like

Please don't start adding weird inscrutable symbols to the Rust language just because we can.

I would hate to see Rust turn into APL.

1 Like

First step is to destigmatize the idea of not always sticking to 7-bit latin-1 compatible characters for language tokens; by merely offering them as an option. Then, in a few generations, maybe humanity will invent a programming-centric keymap that will allow common languages to avoid some of the more prominent ambiguities that increase the complexity of parsers.

I'm really fond of the aesthetics of APL programs.
But I'd never use that programming language, it seems scary to type.

The problem is that while unicode gives us access to millions of code points, 99.99% of keyboards only have 100 or so keys on them.

1 Like

I have programmed in APL. I like the fact that the "strange" characters have no connotations. Each character means exactly what Iverson wanted it to mean.

1 Like

As it happens, yesterday I was presented with a new Macbook Pro M1 to use for work.

Great, except there is no "{", "}", "[", "]" or "|" on the keyboard. How on Earth is one supposed to use this POS?

Of course after twenty minutes of googling around and experimenting I found how to get those characters that are essential for programming.

If the latest and greatest in 2021 cannot handle those basic, good old fashioned brackets easily please don't go adding any new obscure symbols to the language.

Carl Hewitt is developing a language called ActorScript that makes heavy use of non-keyboard characters. I've watched him program using the Windows character picker, and it doesn't look like a terrible experience.

Is there a video of that on YouTube or such like?

Currently in my mind, having to use any kind of GUI character picker to write a program sounds like it has to be a terrible experience. Like messaging on a phone.


True -- though the modifier keys will gives access to plenty more, and we already need to use modifier keys to create common programming tokens.

7-bit ascii is roughly 127 characters (minus a bunch of control characters). If you have ~100 keys * modifier key permutations minus some keys you can't use for generating characters you'll have space for a few more characters. I'm certain it would be possible to squeeze in two extra characters there.

As I wrote:

Then, in a few generations, maybe humanity will invent a programming-centric keymap that will allow common languages to avoid some of the more prominent ambiguities that increase the complexity of parsers.

Slight tangent, but which illustrates where I'm coming from: The Swedish keyboard layout is downright idiotic when it comes to command line use and programming. It gets even worse on a Mac; where someone thought /, | and \ are basically the same thing, so "let's place them all on the same physical key!" (modifier keys aren't evil per se, but you want the more common ones not to be behind modifier key combinations). What this leads to is that some of Swedish developers/administrators discover that it's better to learn and use the US international keyboard for regular work. (Also opens up the possibility to use a computer without problems before the custom keymaps have been loaded..).

At least to me, switching keyboard layouts to a much superior one opened up my mind to the idea that how I had been doing things might not be the best way. In fact, there may be better ways that just never crossed my mind, even with the new and better layout I was now using. Several of my programmer/administrator friends here in Sweden moved on from US International keyboard layout to custom keymaps to remove some annoyances.

My suggestion is merely that perhaps we've outgrown being limited to 7-bit ascii language tokens. And perhaps, just as some of us Swedes realized that there are better keymaps for specific tasks, developers in general might start to think that there are upsides to not being ultra-conservative about keymaps. And language developers might start to think about how Unicode can be used to avoid taking languages in directions they wouldn't need to if they just pulled in one or two extended characters.

I will note that even before I wrote the original post, I was 100% aware that none of these things will happen in my lifetime -- but one of my employees noted that perhaps the younger generations will change the way people think about keymaps when they grow up, because they are much more used to touch screens and their dynamic keyboards. Time will tell, I guess.

No video that I know of. Carl is quite adept at it. One helpful feature is that frequently used characters are cached at the top of the picker, so he almost never has to go searching. On the other hand, I'm a touch typist, so having moving my hand from the keyboard annoys me.

Oddly enough, at the other end of the spectrum I feel the same way.

After decades of programming I am still almost at the "hunt and peck" stage of keyboard use. Confounded by having to move between US, UK, FI and other keyboard layouts along the way.

As such I want what I need under my nose, on the keyboard, rather than have to fumble around to find it in a GUI.

When I started using Mac I was struggling with exactly the same thing, and I discovered "Show Keyboard Viewer" (It's in macOS, no need to download anything). Use it to easily find the keys you're looking for -- no need to google or experiment. (I have a slight memory that the Keyboard Viewer menu item had to be enabled in the settings, but it was many years ago since I did it, so I'm not sure).

But more importantly: Why on earth are you using a Mac with a non-US layout? That's like explicitly asking to make things more inefficient and confusing. If you use a US (International) layout (on both Mac and PC):

  • The keymap on PC/Mac keyboards are vastly more alike [for programming]. In particular the {, }, [, ], | are all in the same place.
  • The keymap is more sane, for programming and command line use, overall.

I noted to one of my friends who's much more of a keyboard geek than I am that the US keyboard is much better for command line and programming, and he remarked "the reason is that the form of the languages/command line interface grew out of the keyboards the developers were using, and the people who developed the Swedish keyboards did not take such things into consideration.". Which is true -- if you use a better keymap you'll struggle far less with both PC and Mac. (There's even a compose-like feature in macOS, so I don't even have to switch to a Swedish keymap to type å, ä and ö).