TMI: More trait inheritance
Feb. 11th, 2013 07:49 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
timOver the weekend I'd been banging on #4183 without much insight. I tried to say everything I knew (which wasn't much) in comments on the issue; this morning I talked to Niko on IRC and as a result of what he said, I decided that #4678 should be fixed first.
The issue in 4183 had to do with the self type in a supertrait bound not getting the type parameter substitutions from the subtrait applied to it (in the code example there, the self type should be T but instead it was getting treated as unsubstituted self, causing an error message about T not matching self). #4678 says we should refactor the code so that the self type is no longer special, but rather, treated (internally to the compiler) as just another type parameter. That's not all that needs to be done -- also, we need to carry around each set of parameter substitutions in a chain of supertrait/subtrait relationships, otherwise T would still be unbound when checking the supertrait bound FuzzyEq<T>. But since #4678 needs to be done anyway, I think it'll be easier to do it first.
I couldn't quite stomach taking that on, though, so instead I went back to my branch where I was trying to finish removing macro code that generates code with structural records. There was a last bit of code in the pipes compiler did this, so I took a stab at removing it, which requires more advanced macrology than I've ever used in Rust before (which is to say, any macrology at all). I ran into a problem with, of all things, one-tuples. That's right, a tuple with only one field. Why would you ever want that? Well, there's a saying that whenever you ask that question in PL, the answer is macros, and in this case, it's macros. It doesn't seem like we parse tuple patterns with a single field properly, so I made a separate branch to just isolate that issue.
And that was Monday.
The issue in 4183 had to do with the self type in a supertrait bound not getting the type parameter substitutions from the subtrait applied to it (in the code example there, the self type should be T but instead it was getting treated as unsubstituted self, causing an error message about T not matching self). #4678 says we should refactor the code so that the self type is no longer special, but rather, treated (internally to the compiler) as just another type parameter. That's not all that needs to be done -- also, we need to carry around each set of parameter substitutions in a chain of supertrait/subtrait relationships, otherwise T would still be unbound when checking the supertrait bound FuzzyEq<T>. But since #4678 needs to be done anyway, I think it'll be easier to do it first.
I couldn't quite stomach taking that on, though, so instead I went back to my branch where I was trying to finish removing macro code that generates code with structural records. There was a last bit of code in the pipes compiler did this, so I took a stab at removing it, which requires more advanced macrology than I've ever used in Rust before (which is to say, any macrology at all). I ran into a problem with, of all things, one-tuples. That's right, a tuple with only one field. Why would you ever want that? Well, there's a saying that whenever you ask that question in PL, the answer is macros, and in this case, it's macros. It doesn't seem like we parse tuple patterns with a single field properly, so I made a separate branch to just isolate that issue.
And that was Monday.