Use assert instead of enforce in std.numeric

[PetarKirov]

... in order to make the code more @nogc and nothrow friendly.

And also use onOutOfMemoryError instead of allocating and throwing a new
exception when malloc fails.

[JackStouffer]

No space after assert. Same throughout

[PetarKirov]

Not in the style guide.

[wilzbach]

Then add it: https://github.com/dlang/dlang.org/edit/master/dstyle.dd ;-)

[dnadlinger]

assert() is by fair the dominant style in Phobos, and matches function calls. Please change it. Thanks.

[PetarKirov]

and matches function calls

Which is why I am against it. But let's agree to disagree for now.

[JackStouffer]

Technically this is a breaking change. I have no opinion on if this should be merged or not but this should get approval from many core team members before getting merged.

[PetarKirov]

All of the changes were cases of irrecoverable errors. enforce should have never been used for them.

[codecov-io]

Current coverage is 88.68% (diff: 88.88%)

Merging #4688 into master will increase coverage by <.01%

@@             master      #4688   diff @@
==========================================
  Files           121        121          
  Lines         73850      73852     +2   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          65494      65497     +3   
+ Misses         8356       8355     -1   
  Partials          0          0          

Powered by Codecov. Last update 79d1195...a724972

[dnadlinger]

All of the changes were cases of irrecoverable errors. enforce should have never been used for them.

That's not true. For example, the enforce in euclideanDistance it's very much a question of API design. Sure, it would be reasonable to declare inputs with mismatching lengths a logic error and just assert on them. But throwing is equally as valid a design decision if you want to accept arbitrary arrays, even if the former might generally preferred in our circles.

[PetarKirov]

I would argue that any code that tries to calculate euclideanDistance of two non equal length ranges has a serious problem.

[dnadlinger]

That might be a valid argument (or might not be, if the vectors come from untrusted input), but it irrelevant here either case. This is a breaking API change, and we need to treat it as such.

[PetarKirov]

AFAIR, there were other PRs that changed enforces to asserts inside .popFront for empty ranges and they were accepted. To me the situation is analogous.

This is a breaking API change, and we need to treat it as such.

I seriously doubt anyone is relying on being able to catch bare Exceptions from std.numeric, but anyway, how would you propose to mitigate the breakage?

[dnadlinger]

You might have a point in so far as the euclideanDistance documentation actually says "The two ranges must have the same length."

I'll leave this to others to decide.

[9il]

LGTM

Will wait for yet another one LGTM from core team before merge

[wilzbach]

For what it is worth needing to catch exceptions in math code makes it slower and annoying to use.
So I like this move, my code wants to be pure nothrow @safe @nogc ;-)
Thanks @ZombineDev

[PetarKirov]

@wilzbach I will make a pass over the module and add pure nothrow @safe @nogc to the unittests, but I first need this PR merged.

[DmitryOlshansky]

These look more like asserts then enforces to me.

[JackStouffer]

@ZombineDev Please add a warning in the changelog about this change

[PetarKirov]

Alright, will do later today.

[PetarKirov]

I added a changelog entry. Let me know if there's anything else I need to do.

[PetarKirov]

Is there a way to see the rendered changelog on @CyberShadow's tester?

[wilzbach]

Is there a way to see the rendered changelog on @CyberShadow's tester?

No sadly not atm - see #4228 for details, for now you can only compile the file on its own with e.g. dmd -D changelog.dd.

[PetarKirov]

Ping @9il @DmitryOlshansky, is there anything else for me to do?

[9il]

Auto-merge toggled on

[PetarKirov]

Thanks, @9il!