Closed Morgane55440 closed 3 months ago
Already done https://github.com/image-rs/imageproc/pull/603
Safety
statement should be used for unsafe
, not for common invariants.
if that's your final decision, then we can close. i don't really care either way as long as the module is updated and everything works.
then should i close this issue ? i guess i mark it as duplicate ?
The following is simply an explanation of the train of thought that lead me to mark new_unchecked
as unsafe
, you should feel free to ignore it, just stating my biased opinion based on my understanding of the rust book.
We can close after merge of proptests
ok !
I'd consider the ordering an internal implementation detail, the unit tests should catch it if the invariants are invalidated, that said debug_assert!()
don't cause any harm so I guess there's no reason not to add them.
To close
in the PR #598 , the subject of the initialization of the struct
morphology::Mask
was raised, in particular as far as data validation is concerned, and the PR was merged before this could be resolved.i am therefore making this issue in order to resolve the matter. (@cospectrum pinging you because you raised the issue first)
currently each constructor calls
Self { elements }
, and data validation comes solely from the algorithms. for example the promises of "reverse lexicographic order" and "no duplicate" is obviously fullfilled by the fact that all the constructors all use some form double loops over strictly increasing ranges, with they
value as the outer loop.of course, modifications of the algorithms could cause these promises to be broken, therefore this is not ideal.
one thing idea that i proposed would be to add warnings about the potential safety concern through a well-documented
unsafe
constructors :this of course has the major disadvantage that it does not do any validation in itself.
therefore we should consider methods of actual validation.
square()
,diamond()
, anddisk()
as they only take au8
as argument and are rather fastdebug_assert
, that would allow optimized build to run as efficiently as possible. this of course should be coupled with testing so that the assertions are checkedthis doesn't need to be in the release as it doesn't impact users, but it shouldn't take long either way