John,
I would suggest requiring *exactly* three slashes for a doc comment (or
*exactly* two stars for a /** -- */ style doc comment). This matches
with Doxygen's parsing (I think), and makes both the examples below
parse correctly.
Erik
On 5/1/2013 11:29 AM, John Clements wrote:
> Currently, the
In thinking about how to handle I/O errors, I came up with a system that
needed a "do" that could take multiple closures (and pass them to
multiple trailing arguments). In thinking about it, this seems
incredibly useful (for non-I/O things), and consistent with how Rust
currently works.
I propose
On 4/29/2013 2:00 PM, Graydon Hoare wrote:
> Yes. Formalizing and completing the definition of the constant
> expression subgrammar would be extremely valuable. It's one of the
> major high-risk areas remaining the the design space. -Graydon
VHDL is a very different language from Rust (it's a hardw
Considering how rarely-used it is (there are eight uses in the
whole compiler), the decision was made to simply reuse "loop"
and save a keyword.
On Fri, Apr 26, 2013 at 3:45 AM, Erik S
<sw...@earthling.net>
wrot
On 4/25/2013 10:53 AM, Patrick Walton wrote:
I'm
not sure we can do the latter. There are too many issues relating
to `unsafe`, `loop`, the `self` argument, etc. to make the LL(1)
derivable from the human-readable grammar in an automated fashion,
in my eyes.
Comments inline. I'm glad to see integer division getting this level
of attention.
Erik
On 4/25/2013 11:12 AM, Matthieu Monrocq
wrote:
Of course, having an infix syntax would make things
easier: 5 % 3 vs 5 rem 3 vs 5
Thanks Graydon for the detailed reply to a newbie suggestion. It looks
like I'm a little too late, this ship has already sailed. You're right
that it's a topic reasonable people can disagree on. Adding Lint
warnings seems like a poor workaround, but maybe the reduced confusion
from C developers wil
On 4/23/2013 9:02 AM, Patrick Walton wrote:
> On 4/23/13 7:48 AM, sw...@earthling.net wrote:
>> Performance should be about the same when using F-division:
>> * Performance will go up for division by constant powers of two.
>> * Performance will stay the same for division by compile-time
>> co
