Currently, in C++, it is possible to pass temporaries to constructors (that
accept a `const&` or rvalue reference type), however, those temporaries are
not lifetime extended, and thus are destroyed at the end of the full
expression (though there are exceptions for certain builtin types, such as
references and std::initializer_list, and for aggregate construction using
list initialization). This is correct for some types (such as owning
container types), but not for types like std::span or
std::reference_wrapper, which borrows it's parameter. As a result, I have a
lot of code like this:

const std::string_view strings[]{"foo"sv,"bar"sv,"baz"sv};
const std::span<const std::string_view> actual_strings_link{strings};

This is used in code where storing "pointers" to arbitrarily sized arrays
is desired (Example using types designed to replace stdlib types:
https://github.com/LightningCreations/lccc/blob/012438ad114526e1ad9fbe4075d718340c3a1d51/xlang/src/Targets/X86.cpp#L49
)
Though noting the (presumably deliberate) lack of an initializer_list
constructor for std::span, it would be nice if this could be rewritten as
something like this, to avoid the single-use static arrays:

const std::span<const std::string_view>
actual_strings_link{"foo"sv,"bar"sv,"baz"sv};

To support this, I propose the [[extend_temporary_lifetime]] attribute. The
attribute can be applied to a const reference, rvalue reference, or
std::initializer_list parameter of a non-copy, non-move constructor. If the
constructor is invoked with a temporary argument in the position of the
temporary, then the lifetime of that temporary is extended to match the
lifetime of the object under construction. If the object being constructed
is a prvalue that initializes another object, the lifetime of the
initialized object is used instead. These rules apply any place lifetime
extension applies: to top level objects, and data members under aggregate
initialization of top level objects. (Notably, a constructor reference
parameter without the attribute used to initialize a non-static data member
will not cause lifetime extension even if it invokes a constructor with
that attribute). Additionally, neither copy nor move construction will
further extend the lifetime of temporaries.

As a side-proposal, but not necessarily required,I also propose the
addition of a std::initializer_list constructor with this attribute, to
std::span. While std::span can be initialized from a value of type
std::initializer_list (due to the range overload), it cannot (
https://godbolt.org/z/osr7nh7EY) be list-initialized. While previously,
such a constructor would be a potential footgun, with this attribute, it
could be used safely and thus would be a nice QOL improvement.
The signature would be:
constexpr explicit(extent!=dynamic_extent)
span([[extend_temporary_lifetime]] std::initializer_list<T>)
and would only participate in overload resolution if const T(*)[] is
convertible to T(*)[].Other than the lifetime extension, the constructor
would act identically to the Range constructor, thus no well-defined code
currently constructing std::span with an initializer_list would be
affected.

Prior Art:
- As mentioned, C++ does perform lifetime extension of "constructor"
arguments in a few cases. When initializing an object of type
std::initializer_list<T> from a braced-init-list, a temporary of type const
T[N] is initialized with the same list, then lifetime extended to that
object (which the initializer_list then refers to). Variables (and statics)
of reference types also benefit from this behaviour. For user-defined
types, aggregate initialization, as mentioned, will perform lifetime
extension for reference and std::initializer_list members.
- In rust, constructors are simple functions, but due to it's explicit
lifetime system, temporary lifetime extension is rather simple to apply.
Consider the Following type which is effectively equivalent to
std::span<const T>:
pub struct ConstSpan<'a,T>{
    data: *const T,
    size: usize,
    lifetime: PhantomData<&'a [T]>
}

impl<'a,T> ConstSpan<'a,T>{
    pub const fn new(slice: &'a [T]) -> ConstSpan<'a,T>{
         Self{data: slice.as_ptr(),size: slice.len(), lifetime: PhantomData}
    }
    // Other methods, indexing/deref impls,
}

In Rust, you could easily construct a ConstSpan from an array using similar
syntax to C++ list-initialization: `ConstSpan::new(&[1,2,3,4]);`. Because
Rust can see the dependency of the return value of new on the parameter, it
knows that the lifetime of the array (which is a temporary) must be at
least as long as the lifetime of the value. While this proposal is nowhere
near as versatile (Rust can even track that dependency when moving/copying
ConstSpan), this proposal provides at least some of that benefit, without
turning C++ into Rust 2.0.

Drawbacks:
- The attribute proposed here would have notable behavioural change between
code that does not use the attribute and code that does. Thus,
implementations would be required to support the attribute (which does not
apply to any other standard attribute). A different syntax form may be
reasonable to indicate this, but an attribute was the first thing I thought
of

Breaking Changes:
- Adding this attribute should not be a breaking change as it does not
affect code that does not use the attribute. Applying the attribute to
functions, however, may be (as it changes the destruction timing of
temporaries it applies to).
- Adding the span method described above would likely not be a breaking
change in reasonable code. However, I do not believe there is a requirement
that std::span not be dangling (it effectively cannot be used while
dangling, but I believe it can be). Thus, this would affect the observable
behaviour of any code that constructs a span (either as a local variable or
static) from a temporary initializer_list, then proceeds to ignore that
span. I do not believe this is affects a significant amount of code.

Additional use in the standard Library:
As mentioned adding this attribute to parameters may cause breaking
changes. However, by the same reasoning, that the number of cases that
would be broken and that don't have undefined behaviour is likely few, I
propose to add the attribute to all of the following constructors in the
Standard Library:
- The Range and Array constructors of std::span
- The upcoming Range constructor of std::basic_string_view.

Specification:

The attribute [[extend_temporary_lifetime]] may be applied to a reference
or std::initializer_list parameter of a constructor, other than a copy or
move constructor. If multiple declarations or definitions of the same
constructor within the same translation unit, then each parameter that has
the attribute in at least one declaration or definition is treated as
though it had the attribute in all subsequent declarations. If a
translation unit declares or defines a constructor with a parameter that
has the attribute, and a different translation unit declares or defines a
constructor that does not apply the attribute to that parameter, the
program is ill-formed, no diagnostic required.

If a complete object, or a subobject initialized during aggregate
initialization of a complete object, with automatic, static, thread, or
lifetime-extended temporary storage duration, is initialized by calling a
constructor other than a copy or a move constructor or a prvalue
initialized in such a way, then if initialization of that object causes a
temporary object to be materialized and bound to a parameter declared with
this attribute, then the temporary object materialized is lifetime-extended
to match the lifetime of the object being initialized.