Make dim check in matrix space creation consistent

[lgoettgens]

Alternative to and thus closes #1711.

All matrix space methods now check r and c in the constructor of the type.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.93%. Comparing base (22e3908) to head (a837dca).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1729      +/-   ##
==========================================
- Coverage   84.93%   84.93%   -0.01%     
==========================================
  Files          95       95              
  Lines       37235    37237       +2     
==========================================
- Hits        31627    31626       -1     
- Misses       5608     5611       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[thofma]

Hm, alternatively one could put them all into the user facing matrix_space functions, right?

[lgoettgens]

Hm, alternatively one could put them all into the user facing matrix_space functions, right?

Yes, it was basically a coin flip what I did

[JohnAAbbott]

Will this be merged soon? I have just ripped out my code (related to #1711), so that I could make PR #1732

[JohnAAbbott]

Just not to lose this observation: it is strange that the ccalls to flint pass the numbers of rows/cols as Int rather than UInt. No doubt there is a reason for this...

[thofma]

Can you explain why you think this is strange?

[JohnAAbbott]

Since the numbers of rows/cols must be non-negative and there is a type for non-negative values, UInt, it seems strange to use a type Int which also allows negative values (which should only lead to errors). I have not looked at the Flint sources...

[thofma]

The ccall arguments must match the signature of the C function.

[JohnAAbbott]

Ah, so my question was really about the flint UI; in C/C++ I understand one being wary of unsigned values.
Thanks for merging!