Comments (10)
it also means that you are not permitted to use turbofish at all
Yep, which is why I did it across the board now rather than planning on adopting it opportunistically. IMHO the way it simplifies function signatures in the docs is worth the small risk that it breaks someone's code, especially since we have a whole slew of minor breaking changes in this version anyway.
from proptest.
0.8.0 is released
from proptest.
rustc version 1.27 … 9 days
Not too bad of a delay I guess, and the things it adds seem worth it.
proptest_derive
I'd personally vote for having a minimum viable release first (eg, without filtering/prob
/recursive types) and then build up from there incrementally rather than a "big bang" release since it doesn't seem like there's a strong need for them to come all at once.
showable & shrinkable closures
I don't feel like this is worth blocking 0.8.0 on; it's not like adding it will be a huge breaking change.
from proptest.
I'd personally vote for having a minimum viable release first
I think that works; I think (but I'm not 100% sure) that prob
and filter
will be strictly additive (no breakage) and recursive logic will most likely need to be opt in and will also probably require some annotations from the user because of undecidability in dealing with mutually recursive types in general.
I don't feel like this is worth blocking 0.8.0 on; it's not like adding it will be a huge breaking change.
Agreed -- I'm quite sure that it is a purely additive change;
Hopefully, I'll be fast enough to land this before 1.27 lands anyways ;)
from proptest.
Since 1.27 only stabilises the arch::{x86,x86_64}
modules and not simd
, is it really worth adding support for that now? The types there are fairly low-level and weakly-typed, which makes precludes any one-size-fits-all support.
from proptest.
Not sure; it should still be possible to implement __m256
and such through _mm256_set_ps
. Should be fairly easy to get good coverage with macros?
My primary motivation for 1.27 is RangeInclusive
tho and to make API consistent on that front.
There are some FIXME
s and TODO
s that are unrelated to 1.27 that I'd like you to look at... primarily in https://github.com/AltSysrq/proptest/blob/0.8.0-changes/src/bits.rs#L30-L31 and https://github.com/AltSysrq/proptest/blob/0.8.0-changes/src/sample.rs#L55-L56 since I am less familiar with those parts..
(Probably won't have time to finish proptest_derive
so that it is polished for a release unfortunately if you want 0.8 shipped in the coming week... but I don't think proptest_derive
influences decisions about proptest
0.8 -- other than to have a nicer release notes)
(Haven't had time to work enough on Showable and Shrinkable Closures -- so it should for sure not block 0.8)
from proptest.
it should still be possible to implement __m256 and such
Possible, yes, but the types aren't well-defined enough for a one-size-fits-all solution.
some FIXMEs and TODOs that are unrelated to 1.27 that I'd like you to look at
Addressed those and all others that looked immediately fixable. Let me know if I missed something; if not, I'll get 0.8.0 published fairly soon.
from proptest.
Possible, yes, but the types aren't well-defined enough for a one-size-fits-all solution.
Alright; Given that we bumped to 1.27, it can be easily added without breakage if we find a good way in the future and someone needs implementations of those :)
Addressed those and all others that looked immediately fixable. Let me know if I missed something; if not, I'll get 0.8.0 published fairly soon.
Nice work! ❤️
I have one concern re. the movement towards impl Trait
in argument position... While it is nice, it also means that you are not permitted to use turbofish at all (not even to specify those type variables which are explicitly quantified that remain). The instances you changed don't seem likely to ever need turbofish, but you never know. I primarily want to highlight the trade-off. I don't mind it being changed to arg: impl Trait
:)
Let me know if I missed something;
https://blog.rust-lang.org/2018/06/21/Rust-1.27.html
In Rust 1.27 you can use dyn Trait
, which we should do instead of the bare trait syntax where trait objects are currently involved. That's just a matter of style tho and can be fixed in a patch version, so it is not urgent.
There's also #[must_use]
which can now be put on functions, which could help users in some cases since strategies usually do nothing unless they are used, for example. In some cases, #[must_use]
should probably be placed on the Strategy
types themselves. For example, Iterator
s in the standard library typically say:
#[must_use = "iterator adaptors are lazy and do nothing unless consumed"]
https://doc.rust-lang.org/nightly/std/iter/struct.Map.html
from proptest.
dyn Trait
Right, I had intended on moving to that. Thanks for pointing it out.
#[must_use]
Good suggestion, I'll see where that applies.
from proptest.
Hurray! 🦀
from proptest.
Related Issues (20)
- First-class support for async functions
- The type 'EasyCashIdentity.EntityLayer.Concrete.AppUser' cannot be used as type parameter
- rust-analyzer doesn't like the derive(Arbitrary) generated code for enums HOT 1
- Zero Examples of `impl Arbitrary` ? HOT 3
- Finite state machines HOT 1
- proptest_derive triggers non-local impl nightly warning HOT 1
- Update "shrinks to" comment on the same seed failures HOT 1
- Panic on empty ranges during strategy creation HOT 3
- Don't require `Arbitrary::Parameters` to implement `Default` HOT 4
- Recursive `arbitrary` calls HOT 3
- Change verbosity of shrink disabled and persisted failure messages HOT 3
- Provide access to state for (debug) printing transitions HOT 5
- feat: add option to interrupt test runner HOT 2
- derive macro for Arbitrary is hard to find HOT 4
- Attribute macro #[property_test] available in docs, but undocumented and behind undocumented feature HOT 1
- Lift MSRV to 1.70 to relax dependency on trybuild
- RangeInclusive of floats containing one element panics
- Improve logging for state machine testing
- The ` state_machine_echo_server` example does not compile HOT 2
- Proptest logging
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proptest.