Let dictionary accept integer keys

[Leedehai]

The proposal seems to have no objections in Discord, other than the argument that dictionaries should still be created like (paint: red, thinkness: 3pt) instead of ("paint": red, "thickness": 3pt), because "Typst should first and foremost be easy for typesetting". This patch respects this.

Please see the demo in tests/typ/compiler/dict.typ and tests/ref/compiler/dict.png. The other tests are still passing.

If accepted, this patch should be merged after #3343.

[Enter-tainer]

the argument that dictionaries should still be created like (paint: red, thinkness: 3pt) instead of ("paint": red, "thickness": 3pt)

i wonder how does this related to this pr? does the first one use integer keys?

[Leedehai]

the argument that dictionaries should still be created like (paint: red, thinkness: 3pt) instead of ("paint": red, "thickness": 3pt)

i wonder how does this related to this pr? does the first one use integer keys?

Not directly. It just came up in Discord, with multiple hops in the train of thoughts. What I attempted to convey here is the change doesn't break existing usage.

[Leedehai]

Converted to a draft as I saw an opportunity of improvement.

[vukovinski]

The proposal seems to have no objections in Discord, other than the argument that dictionaries should still be created like (paint: red, thinkness: 3pt) instead of ("paint": red, "thickness": 3pt), because "Typst should first and foremost be easy for typesetting". This patch respects this.

Please see the demo in tests/typ/compiler/dict.typ and tests/ref/compiler/dict.png. The other tests are still passing.

If accepted, this patch should be merged after #3343.

Hello, just monitoring all of the work here, love the app and seeing a lot of buzz here.

Very suprised by the posters idea that typst should be good for typesetting - yet, now I know better. Thanks.

[Leedehai]

Very suprised by the posters idea that typst should be good for typesetting - yet, now I know better. Thanks.

Hi @vukovinski you could undo the ":confused:" emoji right? It further confuses readers of the PR..

[PgBiel]

I have to mention that I'm not 100% comfortable with this, but let me explain. Ignoring the breaking change aspect (since that isn't really relevant to the discussion), I think dictionaries in Typst have a pretty standard place not only as a way to work with function arguments (I know the arguments type exists, but it's pretty convenient to spread dictionaries), but in general to associate strings with other values.

However, I do understand that having a more general type for mapping non-string values - not just integers, but really anything - to other values is needed, so this is indeed a step in the right direction. But I think we could do it a bit differently. What if, instead of changing the dictionary type, we made a separate map type made only for this purpose (mapping general values to other values)? It would be constructed without a syntax, which would make it pretty clear that we're using arbitrary values as keys. We'd use, for example, tuples (2-element arrays), or we'd group every two arguments in the constructor, or something like that.

[laurmaedje]

I'm not a fan of having a second map type. It feels very duplicate. However, I am concerned about allowing just integers now without a clear plan for allowing other values. If we do not manage to make more or less arbitrary values work, I think I would rather only support strings. There is a big challenges with supporting arbitrary values though: Not everything has the proper Hash/Eq behaviour. f64 with NaN and Content which contains spans which are hashed but that don't affect comparison.

[Leedehai]

I feel supporting strings only as dictionary keys is rather limitive. There are genuine cases where integer keys are needed.

There is a big challenges with supporting arbitrary values though: Not everything has the proper Hash/Eq behaviour.

We could opt for the sensible strategy of supporting using "atomic" values as keys, so it excludes "collective" values like content, array, dictionary etc. As for f64 with NaN - Python hashes it to 0 (until 3.10), or we can simply forbid NaN as a key - I think it's rarely needed in typesetting. If users really want to use uncommon key types, they can always convert them to strings first with str() or repr() right before storing them as keys (the output of repr() is subject to change across Typst versions but it's okay).

[Leedehai]

Wake me up when this will be a thing :)