Simon Krajewski
Simon Krajewski
My intuition would be to instead omit the class from the class output. That way we don't have to mess around in the documentation parser, which would likely introduce really...
I'm confused by the premise here, why do you want to implement null-checks on a type that's not nullable?
It does feel like a fairly Shiro-specific hack rather than a properly thought-out language feature. There's already a lot of complexity with regards to abstracts and null-values, so I'm not...
I kind of understand what you're saying, but isn't this ultimately just syntax sugar? Instead of doing something like `value.isSet()` we do `value == null`, and instead of doing `value.unset()`...
`@:op(A==null)` seems fine and builds on the existing operator overload design. But that doesn't cover the `value = null` case. We don't allow overloading assignment operators, and I'd rather not...
I think that would ironically interfere with the `abstract == null` case because we type the rhs against the lhs, which would give us `abstract == Abstract.fromNullCall()`.
I like this idea a lot, will have to think it through though.
Ah yes, the old 7k function arguments trick, I wonder why that's so slow!
Ah dammit, that means I can't just dismiss this as "crazy". At least not how I originally planned to!
Minimal example: ```haxe import haxe.io.BytesBuffer; macro function makeMess() { return macro $b{[for (i in 0...3000) macro b.addByte($v{i})]}; } function main() { #if !macro var b = new BytesBuffer(); makeMess(); #end...