I only had to deal with the like tax exemption related papers so far and have just winged it - never heard anything from it and I'm not planning to ask them about it again
I’m stuck on the W-7 which literally won’t let me apply for an ITIN (basically an SSN stand-in for tax purposes) until April because of all the silly rules
@Perksey Where is a good place to handle the initial Pointer class generation? also do we have a place where we will make decisions on when we use these types, and would need to add additional higher dimension types?
I’ve just been shoving rarely-used code and scripts somewhere in the
eng
eng
folder.
Not sure what you mean for the second question. The proposal process basically involves us making a decision and documenting it in the proposal (optionally including alternatives), and then debating and/or justifying decision to the working group in a meeting. Often this involves a few proposal revisions before it gets approved.
I meant more in code, the proposal discusses higher dimensions than 3 being built as needed on the fly as needed. I was thinking about whether it was feasible to add those in now as well, whether as as a mod or part of some generation step. If we still aren't sure I can just get the generator stood up and we can decide on how it is used later.
I think 3 is the highest dimension I’ve ever seen in a silk binding, so 3 makes sense until we spot a use case (in the form of a generator crash :P) that warrants increasing it
which is why I’m keen on keeping the generation code you’re writing around in hopes that if that day comes it’s just a case of increasing a number somewhere
The way it is setup currently, I was just going to back it with a binary tree to track what exists and then we request a type to be generated it either generates it on the spot or when we are finished we generate all the types in the tree. This would keep to only the types we need and expand without crashing. Since the types are reliant on the outer type being available (aka PtrMutPtr requires MutPtr) this method should work fairly well and require little upkeep. I would just populate it with the base 3 levels ahead of time to catch the general cases.
i mean we could do that if you wanted to add that to SilkTouchX. i'm keen to have dimensions up to three present in Silk.NET.Core, and also keen to make sure that for Silk.NET first-party we crash if a binding needs more than 4 (so we can add these to Silk.NET.Core instead of potentially multiple assemblies having duplicate higher-dimension pointers), but for third-party users that may not want to use Silk.NET.Core it certainly makes sense