These are chat archives for rust-lang/rust

23rd
Feb 2018
Zakarum
@omni-viral
Feb 23 2018 05:59 UTC
@RReverser let x = y moves y to x. let &x = &y takes reference to y, dereferences it and puts result into x
it'll work only if type of y implements Copy or if x itself is pattern with ref. In those cases let &x = &y and let x = y are same.
So let &x = &y is identical to let x = *&y. And almost the same as let x = y
Yonggang Luo
@lygstate
Feb 23 2018 08:03 UTC
Hello, I am use rust with #![no_std]
, but I have a problem, the format macro can not be used, What should I need to do.
Aleksey Kladov
@matklad
Feb 23 2018 08:19 UTC
@lygstate IIRC, format is not compatible with no_std, because it creates a String, and String are non no_std, because they allocate. However, I think that write! macro might be available in no_std environments
Yonggang Luo
@lygstate
Feb 23 2018 08:20 UTC
Thanks

impl Into<String> for Error {
    fn into(self) -> String {
        match self {
            Error::Validation(s) => s,
            Error::Instantiation(s) => s,
            Error::Function(s) => s,
            Error::Table(s) => s,
            Error::Memory(s) => s,
            Error::Global(s) => s,
            Error::Value(s) => s,
            Error::Trap(s) => write!("trap: {:?}", s),
            Error::Host(e) => write!("user: {}", e),
        }
    }
}
It's told me s format argument must be a string literal.
When I use write instead format
As far as I know alloc also have String, should I use it? use alloc::string::String;
@matklad Thanks
Aleksey Kladov
@matklad
Feb 23 2018 08:31 UTC
@lygstate you need a writer to use write: { let mut buff = String::new(); write!(buff, "foo")}
Katharina Fey
@spacekookie
Feb 23 2018 09:01 UTC
Having skimmed RFC 2126 and comments I'm wondering if everyone on the team is married to the idea of getting rid of mod.rs :sweat_smile: I thought it was kinda neat to be able to read basically anyone's code, look into mod.rs and immediately see what's being exported and a rough overview of how the module was supposed to work
vorner @vorner probably missed that specific RFC. But isn't there going to be some replacement for mod.rs?
Katharina Fey
@spacekookie
Feb 23 2018 09:03 UTC
From what I understood, no? But maybe I overread something
There are a lot of comments :sweat_smile: rust-lang/rfcs#2126
Michal 'vorner' Vaner
@vorner
Feb 23 2018 09:05 UTC
So how would submodules be made? Could they have only one level? Or is nothing supposed to live in the inner node in the module tree? (lot's of comments is probably the reason I haven't found the time to look into yet another module RFC)
Denis Lisov
@tanriol
Feb 23 2018 09:05 UTC
With 2126, the module-level code can live in either $module_name/mod.rs, as before, or $module_name.rs
Katharina Fey
@spacekookie
Feb 23 2018 09:06 UTC

@tanriol Oh you mean the structure could be

main.rs
my_mod/
  bla.rs
my_mod.rs

?

Or just one at a time? Because then that's exactly as it's now :sweat_smile:
Denis Lisov
@tanriol
Feb 23 2018 09:07 UTC
Exactly, the structure can be like this. Or it can be like it was before with mod.rs. Not both :-)
Katharina Fey
@spacekookie
Feb 23 2018 09:07 UTC
Alright
But it's not required. Hmmm, alright
Michal 'vorner' Vaner
@vorner
Feb 23 2018 09:08 UTC
That's probably as good as any other way (perl does that). I'm bit worried about having the option to choose one of them ‒ when examining code, I'll have to check two places and know that I have to check both.
Denis Lisov
@tanriol
Feb 23 2018 09:09 UTC
Probably clippy will have lints on this matter :-)
Katharina Fey
@spacekookie
Feb 23 2018 09:10 UTC
Yea but if you clippy lint for one of them, then why even allow it? xD
Denis Lisov
@tanriol
Feb 23 2018 09:14 UTC
Well, you can just disable a lint, while removing mod.rs support would (a) need to happen on an epoch transition, (b) require everyone to go and move files in their source. Not exactly nice :-)
Dylan DPC
@Dylan-DPC
Feb 23 2018 09:18 UTC
so if you remove mod.rs how do you handle mutiple files in the same module?
Denis Lisov
@tanriol
Feb 23 2018 09:22 UTC
If you have a module foo with submodules, you can just move src/foo/mod.rs to src/foo.rs without changing anything else.
Dylan DPC
@Dylan-DPC
Feb 23 2018 09:23 UTC
no i mean wrt the rfc
Denis Lisov
@tanriol
Feb 23 2018 09:27 UTC
Sorry, I don't understand your question. Is there any pattern that works now, but you don't understand how should it work under the RFC?
Dylan DPC
@Dylan-DPC
Feb 23 2018 09:29 UTC
oh k. give me a moment i'll explain :)
Dylan DPC
@Dylan-DPC
Feb 23 2018 09:53 UTC
nevamind. I guess i got what i wanted :D
Ingvar Stepanyan
@RReverser
Feb 23 2018 14:35 UTC
I think by RFC you can just remove mod.rs and use folder::module directly
So if you don't have it, it will be implicit for all files in folder, which is neat for most cases
Denis Lisov
@tanriol
Feb 23 2018 14:36 UTC
@RReverser In my understanding, you can't.
You still need either mod.rs in the folder or folder.rs outside to contain pub mod module;
Ingvar Stepanyan
@RReverser
Feb 23 2018 14:39 UTC
Oh you're right. I guess I confused with one of the original blog posts with proposal to do that.
Too bad, this would be a neat feature. Hopefully it will come in the future.
Tom Cumming
@tomcumming
Feb 23 2018 15:18 UTC
is there a nice parser crate which doesnt use macros ?
Hans W. Uhlig
@huhlig
Feb 23 2018 15:18 UTC
parsing of what?
Tom Cumming
@tomcumming
Feb 23 2018 15:19 UTC
text
maybe i mean parser combinator
Hans W. Uhlig
@huhlig
Feb 23 2018 15:19 UTC
ahh you want to build a parser
not just parse something
Dylan DPC
@Dylan-DPC
Feb 23 2018 15:31 UTC
you want a LR(1) parser?
then you can try this: https://github.com/lalrpop/lalrpop
not sure if it fits for what you want :D
Katharina Fey
@spacekookie
Feb 23 2018 15:49 UTC
@tanriol Ooh, that's how that is to be read. I kinda interpreted it differently because having foo.rs contain pub mod foo feels super awkward đŸ˜…
Denis Lisov
@tanriol
Feb 23 2018 15:58 UTC
@spacekookie It does not :-)
Katharina Fey
@spacekookie
Feb 23 2018 15:59 UTC
Well I don't really see an advantage over just using a foo/mod.rs file ergonomics wise
Denis Lisov
@tanriol
Feb 23 2018 15:59 UTC
// lib.rs
mod foo;
use foo::bar;
// foo.rs
pub mod bar;
// foo/bar.rs
struct WhatIWantToSeeHere;
You don't need to move foo.rs to foo/mod.rs when you want to add submodules. Oh, and if your editor shows just the filename, you won't have to guess which mod.rs this one is.
Ingvar Stepanyan
@RReverser
Feb 23 2018 16:01 UTC
@tanriol TBH if your editor shows just the filename you're screwed with cargo workspaces too
Katharina Fey
@spacekookie
Feb 23 2018 16:03 UTC
Hmm, yea alright. Not something I really considered. It felt a bit weird because it's like...part of my module aren't actually on the module folder. And I'm a big fan of files into folders :P
Ingvar Stepanyan
@RReverser
Feb 23 2018 16:03 UTC
I really like how VSCode (and I don't remember, but I think Sublime as well and maybe others) does this when they normally show just the filename but if you have several same filenames open, they start showing folder names too
Katharina Fey
@spacekookie
Feb 23 2018 16:04 UTC
:+1: Yea, same
I was kinda looking forward to optionally being able to not have a mod.rsfor modules that only do disjointed things :sweat_smile:
Denis Lisov
@tanriol
Feb 23 2018 16:09 UTC
There were suggestions on automatic module loading without mod declarations, but not in the final RFC.
Katharina Fey
@spacekookie
Feb 23 2018 16:09 UTC
Yea, I read that. Kinda glad it isn't. But that's a different matter entirely
Michal 'vorner' Vaner
@vorner
Feb 23 2018 16:10 UTC
I don't really fancy too much of automatic something… especially if it was done by scanning the directories. If I do cp file.rs broken_file_bak.rs, then I probably don't want that thing to get compiled in.
Katharina Fey
@spacekookie
Feb 23 2018 16:10 UTC
Essentially mod foo for a module where foo/mod.rsor foo.rs doesn't exist loads into scope all public things from foo/*.rs files
Denis Lisov
@tanriol
Feb 23 2018 16:12 UTC
Not as submodules, just as parts of one module?
Katharina Fey
@spacekookie
Feb 23 2018 16:12 UTC
Which would be nice for modules with disjointed atomic members where you save yourself from writing lots of mod statements into the module root file
Ingvar Stepanyan
@RReverser
Feb 23 2018 16:12 UTC
@vorner Well it shouldn't be included if you don't reference it
Katharina Fey
@spacekookie
Feb 23 2018 16:12 UTC
Essentially
Denis Lisov
@tanriol
Feb 23 2018 17:02 UTC
@RReverser How about trait implementations from such a file?
Michael Jansen
@mjjansen
Feb 23 2018 17:27 UTC
is there a simple way to have map_err from Result execute lazily? I see the or_else but i want access to the error before I map it. thank you!
Denis Lisov
@tanriol
Feb 23 2018 17:32 UTC
@mjjansen What do you mean by executing it lazily?
Michael Jansen
@mjjansen
Feb 23 2018 17:32 UTC
only if Result is an error like or_else
Denis Lisov
@tanriol
Feb 23 2018 17:33 UTC
map_err does nothing if the Result is not an error
Michael Jansen
@mjjansen
Feb 23 2018 17:33 UTC
ah. sorry. thank you!
Ingvar Stepanyan
@RReverser
Feb 23 2018 19:03 UTC
@tanriol Heh, that's a good point. My first reaction would be "ignore them unless file is explicitly used at least somewhere" but I can see how inconsistent and ugly that might become.
Katharina Fey
@spacekookie
Feb 23 2018 21:43 UTC
If I compare two strings in rust, is that time safe? i.e. does it always take the same amount of time, depending on length of one of the inputs?
Denis Lisov
@tanriol
Feb 23 2018 21:43 UTC
Default string comparison? I guess not.