Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
I have no idea if it would be feasible in the standard library, but wouldn't the ideal solution be having one function (e.g. from_utf8()) that could return two possible values, a bare result and an Option? Letting the compiler decide which version to use based on type inference like this: let result: ~str = from_utf8(...); let result: Option<~str> = from_utf8(...); Assuming both of them are passed invalid UTF8, then the first version would fail, but the second version would just return None. Again, I don't know if it's possible given the current implementation, but I do think it would be helpful to have a picture of the ideal, and then decide on whatever solution comes closest. As a side note, even if the standard library sticks with two variants for each option function, I would prefer the default one return an Option and have the variant fail on invalid input. Task failure at runtime is a nastier surprise than an invalid type error at compile time, especially for new users who aren't entirely sure of the difference. On Sun, Dec 8, 2013 at 11:58 AM, Carter Schonwald < carter.schonw...@gmail.com> wrote: > Such sugar would would use some sort of monad trait right? > > > On Sunday, December 8, 2013, Ziad Hatahet wrote: > >> On Sat, Dec 7, 2013 at 2:21 PM, Gábor Lehel wrote: >> >>> I do wonder whether it wouldn't make sense to add sugar for Option, at >>> least eventually. (`int?` at the type level is really nice, too... too bad >>> it doesn't play so well with Rust's sigils. Introducing the potential >>> confusion between `~?T` and `?~T` is probably a step too far.) >>> >> >> Wouldn't it be better to add something similar to Haskell's `do` instead >> of another sigil? >> >> >> -- >> Ziad >> >> > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Let’s avoid having both foo() and foo_opt()
Why not have it be an auto-implemented trait like Send or Freeze? On Mon, Dec 9, 2013 at 10:05 AM, Simon Sapin wrote: > On 09/12/2013 15:53, Damien Radtke wrote: > >> I have no idea if it would be feasible in the standard library, but >> wouldn't the ideal solution be having one function (e.g. from_utf8()) >> that could return two possible values, a bare result and an Option? >> Letting the compiler decide which version to use based on type inference >> like this: >> >> let result: ~str = from_utf8(...); >> let result: Option<~str> = from_utf8(...); >> >> Assuming both of them are passed invalid UTF8, then the first version >> would fail, but the second version would just return None. >> >> Again, I don't know if it's possible given the current implementation, >> but I do think it would be helpful to have a picture of the ideal, and >> then decide on whatever solution comes closest. >> > > It is possible to have a generic return value, see for example the > .collect() method of iterators. > > https://github.com/mozilla/rust/blob/4e0cb316fc980f00e1b74f3fdb7a84 > 2b540be280/src/libstd/iter.rs#L447 > > But it involves creating a trait, and implementing it for every supported > type. IMO it’s a lot more involved than what we would want for every > operation that may fail on invalid input. > > > > As a side note, even if the standard library sticks with two variants >> for each option function, I would prefer the default one return an >> Option and have the variant fail on invalid input. Task failure at >> runtime is a nastier surprise than an invalid type error at compile >> time, especially for new users who aren't entirely sure of the difference. >> > > -- > Simon Sapin > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Modules and visibility
I will say that I actually really like Go's approach to modules. It uses a folder -> module mapping instead, so a module can consist of any number of source files provided they all live in the same directory. If you prefer your modules to be one big source file each, then that's easily done, but those who want to break a module up into several files can do so easily. As a counterargument, doesn't the ability to re-export modules effectively give you what you want? It would still be a file -> module mapping, but as far as the user is concerned, they just import one path that gives them everything, giving you the ability to create a module out of sub-modules and therefore keep file size small. I know that Haskell uses this approach. On Thu, Jan 23, 2014 at 5:28 PM, Matthias Einwag < matthias.ein...@googlemail.com> wrote: > Hi, > > > > with similar engineering reasons I can argue the same way that splitting > into multiple makes sense: > > 1. When you name the file like our object you can use jump to file > as a replacement for a Jump to Definition in more complex IDEs. > > 2. When you layout your folders like the module structure is and > the files therin like the types it is quite easy to find the actual file > that defines something. > > 3. When you have multiple types in your module you can use > multiple windows in your editor to work on both in parallel. This is not > necessarily supported if you want two views into the same file at > different positions. > > > > Propably it’s also a matter of taste. Some people like big source files. > Others (like me) don’t like them. > > In several projects or even languages (Java) it’s convention to break > everything down in small parts. > > It shouldn’t be too hard to satisfy everyone here I think . This doesn’t > ask for really big and incompatible changes to the module system. Only for > the option to get rid of the file -> module condition. > > > > PS: Sorry that we now have 2 discussions. One on Github and this one. I > sent it a little bit earlier before seeing the other one. However my intent > is really more the file and privacy thing than discussing about the whole > mod xyz and use:: functionality. > > > > Best regards > > Matthias > > ___ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
[rust-dev] Need help implementing some complex parent-child task behavior.
I'm trying to write what is essentially a card game simulator in Rust, but I'm running into a bit of a roadblock with Rust's memory management. The gist of what I want to accomplish is: 1. In the program's main loop, iterate over several "players" and call their "play" method in turn. 2. Each "play" method should be able to send requests back to the parent in order to take certain actions, who will validate that the action is possible and update the player's state accordingly. The problem I'm running into is that, in order to let a player "play" and have the game validate actions for them, I would need to run each player in their own task, (I considered implementing it as each function call indicating a request for action [e.g. by returning Some(action), or None when finished] and calling it repeatedly until none are taken, but this makes the implementation for each player needlessly complex) but this makes for some tricky situations. My current implementation uses a DuplexStream to communicate back and forth, the child sending requests to the parent and the parent sending responses, but then I run into the issue of how to inform the child of their current state, but don't let them modify it outside of sending action requests. Ideally I'd like to be able to create an (unsafe) immutable pointer to the state held by the parent as mutable, but that gives me a "values differ in mutability" error. Other approaches so far have failed as well; Arcs don't work because I need to have one-sided mutability; standard borrowed pointers don't work because the child and parent need to access it at the same time (though only the parent should be able to modify it, ensuring its safety); even copying the state doesn't work because the child then needs to update its local state with a new copy sent by the parent, which is also prone to mutability-related errors. Any tips on how to accomplish something like this? ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
Unfortunately, the type that maintains the state apparently doesn't fulfill Send, which confuses me because it's a struct that consists of a string, function pointer, and a few dynamically-sized vectors. Which of these types makes the struct as a whole violate Send? On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard wrote: > What if the state's fields are private, and in a different module than the > players, but exposes getters to query the state? Then the players can't > modify it, but if the component that processes the actions has visibility > into the state's fields, it can modify them just fine. > > -Kevin > > On Feb 14, 2014, at 12:22 PM, Damien Radtke > wrote: > > > I'm trying to write what is essentially a card game simulator in Rust, > but I'm running into a bit of a roadblock with Rust's memory management. > The gist of what I want to accomplish is: > > > > 1. In the program's main loop, iterate over several "players" and call > their "play" method in turn. > > 2. Each "play" method should be able to send requests back to the parent > in order to take certain actions, who will validate that the action is > possible and update the player's state accordingly. > > > > The problem I'm running into is that, in order to let a player "play" > and have the game validate actions for them, I would need to run each > player in their own task, (I considered implementing it as each function > call indicating a request for action [e.g. by returning Some(action), or > None when finished] and calling it repeatedly until none are taken, but > this makes the implementation for each player needlessly complex) but this > makes for some tricky situations. > > > > My current implementation uses a DuplexStream to communicate back and > forth, the child sending requests to the parent and the parent sending > responses, but then I run into the issue of how to inform the child of > their current state, but don't let them modify it outside of sending action > requests. > > > > Ideally I'd like to be able to create an (unsafe) immutable pointer to > the state held by the parent as mutable, but that gives me a "values differ > in mutability" error. Other approaches so far have failed as well; Arcs > don't work because I need to have one-sided mutability; standard borrowed > pointers don't work because the child and parent need to access it at the > same time (though only the parent should be able to modify it, ensuring its > safety); even copying the state doesn't work because the child then needs > to update its local state with a new copy sent by the parent, which is also > prone to mutability-related errors. > > > > Any tips on how to accomplish something like this? > > ___ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
The function pointer is indeed a function pointer and all of the strings and vectors are ~, but the vector type is &'static. They're meant to hold references to card definitions, which is more efficient than passing around the cards themselves. I tried modifying the vectors to hold ~-strings instead, but it still didn't work. Looks like I'll need to do more research on Send. On Fri, Feb 14, 2014 at 3:19 PM, Kevin Ballard wrote: > Depends. If the string or the vectors are & instead of ~, that would do > it. Also, if the element type of the vector does not fulfill Send. Oh, and > the function pointer is a function pointer, not a closure, right? > > -Kevin > > On Feb 14, 2014, at 12:59 PM, Damien Radtke > wrote: > > Unfortunately, the type that maintains the state apparently doesn't > fulfill Send, which confuses me because it's a struct that consists of a > string, function pointer, and a few dynamically-sized vectors. Which of > these types makes the struct as a whole violate Send? > > > On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard wrote: > >> What if the state's fields are private, and in a different module than >> the players, but exposes getters to query the state? Then the players can't >> modify it, but if the component that processes the actions has visibility >> into the state's fields, it can modify them just fine. >> >> -Kevin >> >> On Feb 14, 2014, at 12:22 PM, Damien Radtke >> wrote: >> >> > I'm trying to write what is essentially a card game simulator in Rust, >> but I'm running into a bit of a roadblock with Rust's memory management. >> The gist of what I want to accomplish is: >> > >> > 1. In the program's main loop, iterate over several "players" and call >> their "play" method in turn. >> > 2. Each "play" method should be able to send requests back to the >> parent in order to take certain actions, who will validate that the action >> is possible and update the player's state accordingly. >> > >> > The problem I'm running into is that, in order to let a player "play" >> and have the game validate actions for them, I would need to run each >> player in their own task, (I considered implementing it as each function >> call indicating a request for action [e.g. by returning Some(action), or >> None when finished] and calling it repeatedly until none are taken, but >> this makes the implementation for each player needlessly complex) but this >> makes for some tricky situations. >> > >> > My current implementation uses a DuplexStream to communicate back and >> forth, the child sending requests to the parent and the parent sending >> responses, but then I run into the issue of how to inform the child of >> their current state, but don't let them modify it outside of sending action >> requests. >> > >> > Ideally I'd like to be able to create an (unsafe) immutable pointer to >> the state held by the parent as mutable, but that gives me a "values differ >> in mutability" error. Other approaches so far have failed as well; Arcs >> don't work because I need to have one-sided mutability; standard borrowed >> pointers don't work because the child and parent need to access it at the >> same time (though only the parent should be able to modify it, ensuring its >> safety); even copying the state doesn't work because the child then needs >> to update its local state with a new copy sent by the parent, which is also >> prone to mutability-related errors. >> > >> > Any tips on how to accomplish something like this? >> > ___ >> > Rust-dev mailing list >> > Rust-dev@mozilla.org >> > https://mail.mozilla.org/listinfo/rust-dev >> >> > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
Ah, I think the problem is that I'm trying to create a new task within a loop over an iterator, so each value is an &-ptr and is therefore causing it to fail... On Fri, Feb 14, 2014 at 4:12 PM, Damien Radtke wrote: > The function pointer is indeed a function pointer and all of the strings > and vectors are ~, but the vector type is &'static. They're meant to hold > references to card definitions, which is more efficient than passing around > the cards themselves. I tried modifying the vectors to hold ~-strings > instead, but it still didn't work. > > Looks like I'll need to do more research on Send. > > > On Fri, Feb 14, 2014 at 3:19 PM, Kevin Ballard wrote: > >> Depends. If the string or the vectors are & instead of ~, that would do >> it. Also, if the element type of the vector does not fulfill Send. Oh, and >> the function pointer is a function pointer, not a closure, right? >> >> -Kevin >> >> On Feb 14, 2014, at 12:59 PM, Damien Radtke >> wrote: >> >> Unfortunately, the type that maintains the state apparently doesn't >> fulfill Send, which confuses me because it's a struct that consists of a >> string, function pointer, and a few dynamically-sized vectors. Which of >> these types makes the struct as a whole violate Send? >> >> >> On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard wrote: >> >>> What if the state's fields are private, and in a different module than >>> the players, but exposes getters to query the state? Then the players can't >>> modify it, but if the component that processes the actions has visibility >>> into the state's fields, it can modify them just fine. >>> >>> -Kevin >>> >>> On Feb 14, 2014, at 12:22 PM, Damien Radtke >>> wrote: >>> >>> > I'm trying to write what is essentially a card game simulator in Rust, >>> but I'm running into a bit of a roadblock with Rust's memory management. >>> The gist of what I want to accomplish is: >>> > >>> > 1. In the program's main loop, iterate over several "players" and call >>> their "play" method in turn. >>> > 2. Each "play" method should be able to send requests back to the >>> parent in order to take certain actions, who will validate that the action >>> is possible and update the player's state accordingly. >>> > >>> > The problem I'm running into is that, in order to let a player "play" >>> and have the game validate actions for them, I would need to run each >>> player in their own task, (I considered implementing it as each function >>> call indicating a request for action [e.g. by returning Some(action), or >>> None when finished] and calling it repeatedly until none are taken, but >>> this makes the implementation for each player needlessly complex) but this >>> makes for some tricky situations. >>> > >>> > My current implementation uses a DuplexStream to communicate back and >>> forth, the child sending requests to the parent and the parent sending >>> responses, but then I run into the issue of how to inform the child of >>> their current state, but don't let them modify it outside of sending action >>> requests. >>> > >>> > Ideally I'd like to be able to create an (unsafe) immutable pointer to >>> the state held by the parent as mutable, but that gives me a "values differ >>> in mutability" error. Other approaches so far have failed as well; Arcs >>> don't work because I need to have one-sided mutability; standard borrowed >>> pointers don't work because the child and parent need to access it at the >>> same time (though only the parent should be able to modify it, ensuring its >>> safety); even copying the state doesn't work because the child then needs >>> to update its local state with a new copy sent by the parent, which is also >>> prone to mutability-related errors. >>> > >>> > Any tips on how to accomplish something like this? >>> > ___ >>> > Rust-dev mailing list >>> > Rust-dev@mozilla.org >>> > https://mail.mozilla.org/listinfo/rust-dev >>> >>> >> >> > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Need help implementing some complex parent-child task behavior.
So I managed to implement a solution without needing a child task, using Kevin's initial idea of a struct with private fields and public getters. The idea had occurred to me but I wasn't sure exactly how to implement it; needless to say, I think I was overcomplicating things. Thanks for the help, Kevin. On Fri, Feb 14, 2014 at 4:18 PM, Damien Radtke wrote: > Ah, I think the problem is that I'm trying to create a new task within a > loop over an iterator, so each value is an &-ptr and is therefore causing > it to fail... > > > On Fri, Feb 14, 2014 at 4:12 PM, Damien Radtke wrote: > >> The function pointer is indeed a function pointer and all of the strings >> and vectors are ~, but the vector type is &'static. They're meant to hold >> references to card definitions, which is more efficient than passing around >> the cards themselves. I tried modifying the vectors to hold ~-strings >> instead, but it still didn't work. >> >> Looks like I'll need to do more research on Send. >> >> >> On Fri, Feb 14, 2014 at 3:19 PM, Kevin Ballard wrote: >> >>> Depends. If the string or the vectors are & instead of ~, that would do >>> it. Also, if the element type of the vector does not fulfill Send. Oh, and >>> the function pointer is a function pointer, not a closure, right? >>> >>> -Kevin >>> >>> On Feb 14, 2014, at 12:59 PM, Damien Radtke >>> wrote: >>> >>> Unfortunately, the type that maintains the state apparently doesn't >>> fulfill Send, which confuses me because it's a struct that consists of a >>> string, function pointer, and a few dynamically-sized vectors. Which of >>> these types makes the struct as a whole violate Send? >>> >>> >>> On Fri, Feb 14, 2014 at 2:47 PM, Kevin Ballard wrote: >>> >>>> What if the state's fields are private, and in a different module than >>>> the players, but exposes getters to query the state? Then the players can't >>>> modify it, but if the component that processes the actions has visibility >>>> into the state's fields, it can modify them just fine. >>>> >>>> -Kevin >>>> >>>> On Feb 14, 2014, at 12:22 PM, Damien Radtke >>>> wrote: >>>> >>>> > I'm trying to write what is essentially a card game simulator in >>>> Rust, but I'm running into a bit of a roadblock with Rust's memory >>>> management. The gist of what I want to accomplish is: >>>> > >>>> > 1. In the program's main loop, iterate over several "players" and >>>> call their "play" method in turn. >>>> > 2. Each "play" method should be able to send requests back to the >>>> parent in order to take certain actions, who will validate that the action >>>> is possible and update the player's state accordingly. >>>> > >>>> > The problem I'm running into is that, in order to let a player "play" >>>> and have the game validate actions for them, I would need to run each >>>> player in their own task, (I considered implementing it as each function >>>> call indicating a request for action [e.g. by returning Some(action), or >>>> None when finished] and calling it repeatedly until none are taken, but >>>> this makes the implementation for each player needlessly complex) but this >>>> makes for some tricky situations. >>>> > >>>> > My current implementation uses a DuplexStream to communicate back and >>>> forth, the child sending requests to the parent and the parent sending >>>> responses, but then I run into the issue of how to inform the child of >>>> their current state, but don't let them modify it outside of sending action >>>> requests. >>>> > >>>> > Ideally I'd like to be able to create an (unsafe) immutable pointer >>>> to the state held by the parent as mutable, but that gives me a "values >>>> differ in mutability" error. Other approaches so far have failed as well; >>>> Arcs don't work because I need to have one-sided mutability; standard >>>> borrowed pointers don't work because the child and parent need to access it >>>> at the same time (though only the parent should be able to modify it, >>>> ensuring its safety); even copying the state doesn't work because the child >>>> then needs to update its local state with a new copy sent by the parent, >>>> which is also prone to mutability-related errors. >>>> > >>>> > Any tips on how to accomplish something like this? >>>> > ___ >>>> > Rust-dev mailing list >>>> > Rust-dev@mozilla.org >>>> > https://mail.mozilla.org/listinfo/rust-dev >>>> >>>> >>> >>> >> > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
