Le 21/09/2013 16:38, Olivier Renaud a écrit :
I'd expect this offset to be absolute. After all, the only thing that the
programmer can do with this information at this point is to report it to the
user ; if the programmer wanted to handle the error, he could have done it by
using a trap. A relati
Hi everyone,
Have we considered syntax similar to Ruby style heredocs? I particularly
like the light looking syntax.
- The indentation of the block is determined by the indentation of the eos
marker. Keeping code flow natural.
< wrote:
> > Of the 3, Lua's is probably the best, although it's a b
Andrew and I are on the same thinking path.. a REPL does not have to crash,
nor a process that it tries to understand, and the word should not be in
its vocabulary...just make sure it can handle the idea of "I do not know
what to do here...so I will just ignore this process and continue on with
my
I must be missing something about ruby heredocs, but the indentation had
always been a painful question about them (
http://stackoverflow.com/questions/3772864/how-do-i-remove-leading-whitespace-chars-from-ruby-heredoc).
Another thing, of course, it's that they are by no means raw (which of
course
Heredocs are primarily intended for multiline strings. Raw strings are intended
for strings that have no escapes. Raw strings typically allow newlines, but
that is not their primary purpose (and in Rust, regular strings allow newlines
anyway). Trying to use a heredoc syntax for raw strings is ju
Oh right, that's fair enough. I think the indentation/escaping issues can
be fixed however the new line issues you mentioned will still exist for
strings split over multiple lines using this syntax.
Good luck!
Steven
On Monday, September 23, 2013, Kevin Ballard wrote:
> Heredocs are primarily i
I'm in favour of C++11 syntax.
On Monday, September 23, 2013, Steven Ashley wrote:
> Oh right, that's fair enough. I think the indentation/escaping issues can
> be fixed however the new line issues you mentioned will still exist for
> strings split over multiple lines using this syntax.
>
> Good
On Thu, Sep 19, 2013 at 1:36 PM, Kevin Ballard wrote:
> One feature common to many programming languages that Rust lacks is "raw"
> string literals.
This is one of those things where I feel almost all languages get wrong,
and probably mostly for historical reasons. IMO there should *only* be ra
I've filed a summary of this conversation as an RFC issue on the GitHub issue
tracker.
https://github.com/mozilla/rust/issues/9411
-Kevin
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Hi, in various places on the mailing list and in the docs there is mention
of 'syntax extensions' or 'compiled syntax extensions' - some method of
extending the syntax of Rust which is compiled into the compiler, rather
than using macros. Are there any docs for these? Or is there any code which
is
On 09/22/2013 05:40 PM, Kevin Ballard wrote:
I've filed a summary of this conversation as an RFC issue on the GitHub issue
tracker.
https://github.com/mozilla/rust/issues/9411
I've used a variation of the option 10 for my own configuration format's
raw strings:
delim"raw text"delim
Where
' doesn't work because 'delim is parsed as a lifetime.
-Kevin
On Sep 22, 2013, at 3:41 PM, SiegeLord wrote:
> On 09/22/2013 05:40 PM, Kevin Ballard wrote:
>> I've filed a summary of this conversation as an RFC issue on the GitHub
>> issue tracker.
>>
>> https://github.com/mozilla/rust/issues/
On 09/22/2013 07:10 PM, Kevin Ballard wrote:
' doesn't work because 'delim is parsed as a lifetime.
The parser will have to be modified to support raw strings in any of
their manifestations. Is it a fact that there is no possible parser than
can differentiate between 'delim and 'delim" ? I gu
It would require changing the rules for lifetimes, with no benefit (and no
clear new rule to use anyway). &'foo"delim" is perfectly legal today, and I see
no reason to change that.
-Kevin
On Sep 22, 2013, at 4:26 PM, SiegeLord wrote:
> On 09/22/2013 07:10 PM, Kevin Ballard wrote:
>> ' doesn't
On 09/22/2013 07:45 PM, Kevin Ballard wrote:
It would require changing the rules for lifetimes, with no benefit (and no clear new rule to
use anyway). &'foo"delim" is perfectly legal today, and I see no reason to
change that.
It's not as big a change as you make it out to be, but fair enough.
On Sep 22, 2013, at 5:27 PM, SiegeLord wrote:
> On 09/22/2013 07:45 PM, Kevin Ballard wrote:
>> It would require changing the rules for lifetimes, with no benefit (and no
>> clear new rule to use anyway). &'foo"delim" is perfectly legal today, and I
>> see no reason to change that.
> It's not a
16 matches
Mail list logo
