4 ms·
Very clever. It may be robust, but is ridiculously verbose and feels sorta obfuscatory. Also pays a runtime penalty unless they've improved the CLR codegen. It
by MichaelGG 12y ago
Very clever. It may be robust, but is ridiculously verbose and feels sorta obfuscatory. Also pays a runtime penalty unless they've improved the CLR codegen.
It also might not be super amenable to static analysis.
- noblethrasher 12y agoBut, structs pay a very small runtime penalty, if at all, right? The verbosity will be mostly ameliorated with primary constructor. I propose going further by allowing programmers to annotate constructors so that they can be used as user-defined conversion operators. Thus, the aforementioned code could become something like: public struct GreaterThanFive implicit (int n) { readonly int n = n; if(n <= 5) throw new ArgumentException("n must be greater than 5"); }
- MichaelGG 12y agoTraditionally, structs paid a large codegen penalty, as a lot of optimizations and stuff were turned off. It also seemed like the codegen wasn't super smart about passing them around. Maybe that's all changed. I meant the verbosity of having to create a custom type for each kind of restriction, versus some inline "int n [n > 5]" notation.
- noblethrasher 12y agoIn addition to the benefit of brevity, something like your proposal also has the virtue of being compatible with the `checked/unchecked` keywords.