type variables

Bruce Carneal bcarneal at gmail.com
Sun Aug 2 06:36:44 UTC 2020

On Sunday, 2 August 2020 at 04:08:00 UTC, Bruce Carneal wrote:
> Factoring out naming from the "anonymous" structural aspects of 
> types seems like a good way to go.  If people want to match on 
> type structure for some reason, great.  If they want to create 
> ginormous names, well, OK.

Did some background reading on LLVM.  The LLVM type system 
provides both named and unnamed literal/structural forms.

Type equality checks within LLVM, both named and otherwise, 
appear to be non-trivial in general (saw a 2020 paper 
highlighting the screw-ups and workarounds).

Earlier LLVM work aimed to speed things up there by reducing the 
cost of "uniqueing" mutable type representations (turning 
deep/expensive equality checks in to pointer comparisons IIUC).  
As a guess, DMD already does this type of thing, separating 
deeper commonalities from shallower differences (names, 
attributes, and the like).

Looks like many of LLVM's more recent problems stem from C/C++ 
related issues.  Again not a problem for DMD.

Still, even concrete/lowered type representation is much less a 
"solved" problem than I imagined if LLVM is anything to go by.

The improvements suggested by Manu and Stefan are looking pretty 

More information about the Digitalmars-d mailing list