On 10-09-17 01:32 PM, Peter Hull wrote:
I think there's two points here. I must admit I found it a bit hard work _writing_ fasta - I didn't realise how much I relied on C's integer promotion rules. But I think that can be overcome with a bit of mental discipline.
There is also a matter of API choice; we presently have our various indexing and length-related functions all defined in terms of uint. This is "more correct" in the sense that there's no meaning to a negative index; but it is awkward and in a way that a simple "pragma uint" won't necessarily correct (you'd suddenly find yourself writing 3i in the non-uint cases).
We could also just change some portion of the relevant APIs to use ints.
The second point is whether the suffixes obscure the meaning of the code when _reading_ it. I think they do to some extent but not too badly.
Yeah. Hard to say. It's a bit chatty.
Is it possible to infer the type from the expression, e.g. in 2 + x the 2 matches the declared type of x?
Plausible. Go takes a similar angle on this; their numeric literals are "untyped" and acquire a type via inference from the context. I'm not sure I'm really keen on that -- every additional complication to inference is a bit of a penalty to implementers, tools and future readers -- but it could work.
Any feelings from others? Particularly .. those who have worked on the type inference module :)
Also is it possible to modify the emacs rust-mode to show the suffix in a different colour?
Probably; I'm not an expert in CC-mode but I'd be happy to take a patch. -Graydon _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
