Hacker News Reader

Comment by carterschonwald | Hacker News Reader

I think this a great way of presenting type features that interact! props to the author for cooking it up

> I think this a great way of presenting type features that interact! props to the author for cooking it up

It's a great way to present it, but like Scala's infamous "Periodic Table of Dispatch Operators", stuff like is rather off putting. Why use crude sigils when you could just as well use easily understood keywords (like ref, out, unsafe etc. in C-Sharp)?

Funny enough, ~ sigil will probably be retiring in favor of box.

    let x = ~"Thing"; //old code
    let x = box Thing // new code probably

Note: I said probably because it's probably because:

A) Not sure it will be implemented

B) Not sure if that will be syntax

--- PS. Any link to dispatch operator periodic table?

Also I take your scala and raise you a Perl: http://glyphic.s3.amazonaws.com/ozone/mark/periodic/Periodic...

Re: the dispatch periodic table. This is from a library in Scala (a web client called dispatch) that was someone's first project in Scala and went very overboard on the use of operators. It is generally considered bad design.

The Dispatch periodic table is here:

http://www.flotsam.nl/dispatch-periodic-table.html

Just to avoid any misunderstandings: The linked page is a (very nicely done) joke. These are not Scala operators, but (by now retired) operators of a particular third party library for Http dispatch.

That's a shame, I happen to like the use of sigils to denote pointer types, to my eyes it makes code a lot easier to read.

Out of curiosity why are they making the change? And will they add the `let x = box Thing` syntax or as an optional addition to the language or will it fully replace the old `let = ~Thing` syntax?

I think the idea is to make heap allocation taxing to type. Basically the sigil is too easy to type, so its easy for application to just allocates a whup ass of memory. So, this way it might force you to think about each allocation.

It's nice to have very common features be syntactically lightweight, and sigils are incredibly lightweight compared to two-or-three character keywords. Rust code uses these pointers in all but the most trivial code, so they'll be showing up a lot; in contrast, I suspect as a non-C# programmer that ref and out are not as widely used in most C# codebases as ~ and & are in Rust. There are also not that many sigils, all told—three sigils for pointers plus a few other operators that appear in this table.

Additionally, this table is different from the tables of Scala dispatch operators, Perl operators, &c because of its regularity—it has two axes and a good deal of the information presented is a straightforward function of a cell's position in the table[1]. For example, the entry in the Owned column and the String row is going to be an... owned string, which is going to be prefixed with ~ (like every cell in the Owned column) and have a base type of str (like every cell in the String row). This is a far cry from the table of Scala's dispatch operators, in which there's no consistent indication of what a given operator will necessarily do aside from a general grouping of like operators.

[^1, edit]: That isn't to say that ALL the information is a (predictable) function of a cell's position in the table. Some of that irregularity comes from arguably expected consequences of Rust semantics (e.g. of course you can't have a bare string, because you can only have bare values whose sizes are known in advance, and you don't know how long a string will be) while some is genuinely arbitrary, like the syntactic sugar for functions.

And one of those sigils has effectively been deprecated, it's just & and ~ now. And ~ might turn into `box`.

My understanding was that `box` would be for allocation, but type definitions still need to have the ~ sigil. But I could be mistaken.

Reply on news.ycombinator.com