You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be awesome to support building constant lookup tables at compile-time similar to gperf. This is a really common pattern and could potentially be a big performance win in many places (I'm sure rustc has a lot of constant tables).
A really simple proof of concept would sort an array and provide an object implementing the core::container::Map interface (once MutableMap is split out) via binary search.
The naming would be something along the lines of map!, set!, ordered_map! and ordered_set! along with the corresponding types ConstantMap, ConstantSet, ConstantOrderedMap, ConstantOrderedSet.
The text was updated successfully, but these errors were encountered:
Agreed, but I think this would make a better 3rd party library (once syntax extensions are independently loadable) rather than necessarily part of the main compiler. I'll leave it open here since we don't have a syntax-extensions-wanted page yet.
A macro could easily be created that would provide a nicer syntax for this. Is there any reason that a hash table could not be used to implement big enough to benefit match expressions?
It would be awesome to support building constant lookup tables at compile-time similar to gperf. This is a really common pattern and could potentially be a big performance win in many places (I'm sure rustc has a lot of constant tables).
A really simple proof of concept would sort an array and provide an object implementing the
core::container::Map
interface (onceMutableMap
is split out) via binary search.The naming would be something along the lines of
map!
,set!
,ordered_map!
andordered_set!
along with the corresponding typesConstantMap
,ConstantSet
,ConstantOrderedMap
,ConstantOrderedSet
.The text was updated successfully, but these errors were encountered: