Add enable_if restriction for span constructor from c array

[mike919192]

A small change to the static span constructor from c array to require that Extent is equal to Array_Size. std span on gcc also does this same check.

This prevents the following code from compiling:

int arr[5]{};
etl::span<int, 10> span1(arr);  //currently no compile error here.  equivalent std span on gcc does have compile error

[jwellbelove]

I don't think the (Extent == etl::dynamic_extent) test is necessary here, as this class specialisation is for fixed extent only.

[mike919192]

I think you are right! But I was following the style of the other code in the fixed span, where there are also checks for either == or != etl::dynamic_extent. Still I can try removing it in this constructor, I think all the unit tests should still be good.

[jwellbelove]

But I was following the style of the other code in the fixed span

I'll take a look at the other code.

[jwellbelove]

I was wondering whether I should add a runtime check for when a dynamic etl::span is used to copy construct to a larger fixed etl::span. In the STL it seems to be classed as just 'undefined behaviour' in release mode.

[mike919192]

I was wondering whether I should add a runtime check for when a dynamic etl::span is used to copy construct to a larger fixed etl::span. In the STL it seems to be classed as just 'undefined behaviour' in release mode.

I took a look at how how gcc handles this.

std::vector<int> vec {0, 1, 2, 3, 4};
std::span test1(vec);
std::span<int, 10> test2(test1);

In the constructor for test2, there is a debug assert that test2::Extent == test1.size(). So I could see if being reasonable to do something similar with an ETL_ASSERT.

I would hope that I wouldn't run into this case much. Constructing a fixed span from a dynamic just seems like a bad idea, but mistakes can happen.

Edit: Ah, just realized the constructor is noexcept. So one more thing to keep in mind.