On Wednesday, 19 August 2015 at 02:08:08 UTC, H. S. Teoh wrote:
#8: ah, the good ole controversial bitshift operators... esp.
the still unresolved controversy surrounding the behaviour of
>> vs. >>> (sorry, forgot the bug number, but it's in
bugzilla). IMO, we should ditch these operators and use int
intrinsics for the assembly instructions instead. What's the
use of built-in operators that are only occasionally used in
system code? Something like 1.shiftLeft(2) would work just
fine in expressions, and simplify the lexer by having less
token types.
I'm not sure about making a separate type for ints-as-bits,
though. That seems a bit extreme, and would almost imply that
non-bitarray numbers would have to be BigInt by default.
I like this point. I rarely see those operators, but it's usually
in some kind of highly optimized code that is impossible to
follow (maybe the compiler uses these more?). Also, every time I
see a >> I always think much bigger than, which of course doesn't
make any sense. 1.shiftleft(2) is actually much more intuitive to
me.
#5: seems like just syntax nitpicking... though in the case of
D, the current schizophrenic split between attributes on the
left vs. attributes on the right is another example of
needlessly convoluted syntax.
I agree with both points. Nevertheless, it does seem like a lot
of newer languages have adopted this style. Rush and Go both have
the type follow the name of the variable. I could add Julia and
Python's mypy to that as well. I had downloaded some introduction
to homotopy type theory, which I did not understand more than a
few pages of, and it also used the name : type approach, so I
imagine it is being used more broadly in mathematical type
theories.
Anyway, I can't imagine this would ever be adopted for D. It
conflicts with too much stuff, most notably inheritance and
template specialization, at this point.
