@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
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.
, but I have a problem, the format macro can not be used, What should I need to do.
@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
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),
}
}
}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
@lygstate you need a writer to use write:
{ let mut buff = String::new(); write!(buff, "foo")}
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?
From what I understood, no? But maybe I overread something
There are a lot of comments :sweat_smile: rust-lang/rfcs#2126
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)
With 2126, the module-level code can live in either
$module_name/mod.rs, as before, or $module_name.rs
@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:
Exactly, the structure can be like this. Or it can be like it was before with
mod.rs. Not both :-)
Alright
But it's not required. Hmmm, alright
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.
Probably
clippy will have lints on this matter :-)
Yea but if you clippy lint for one of them, then why even allow it? xD
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 :-)
so if you remove
mod.rs how do you handle mutiple files in the same module?
If you have a module
foo with submodules, you can just move src/foo/mod.rs to src/foo.rs without changing anything else.
no i mean wrt the rfc
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?
oh k. give me a moment i'll explain :)
nevamind. I guess i got what i wanted :D
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
@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;
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.
is there a nice parser crate which doesnt use macros ?
parsing of what?
text
maybe i mean parser combinator
ahh you want to build a parser
not just parse something
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
@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 đŸ˜…
@spacekookie It does not :-)
Well I don't really see an advantage over just using a
foo/mod.rs file ergonomics wise
// 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.
@tanriol TBH if your editor shows just the filename you're screwed with cargo workspaces too
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
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
:+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:
There were suggestions on automatic module loading without
mod declarations, but not in the final RFC.
Yea, I read that. Kinda glad it isn't. But that's a different matter entirely
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.
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
Not as submodules, just as parts of one module?
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
@vorner Well it shouldn't be included if you don't reference it
Essentially
@RReverser How about trait implementations from such a file?
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!
@mjjansen What do you mean by executing it lazily?
only if
Result is an error like or_else
map_err does nothing if the Result is not an error
ah. sorry. thank you!
@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.
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?
Default string comparison? I guess not.