X>for ( auto idx: {34..56} ) {}
X>for ( auto idx: {34,56} ) {}
X>

for ( auto idx: "34..56"_range ) {}

template<typename T, typename A>
class dynarray {
   T* start_;
   T* finish_;
   static if (!is_empty<A>::value) {
      A alloc_;
   }
};

// Although may seem like an elegant alternative, the impact 
// on the class’s implementation is far less so.
// For example, how would we write a constructor?
template<typename T, typename A>
dynarray<T, A>::dynarray(size_t n, T value, const A& alloc)
   :start_(alloc.allocate(n * sizeof(T))
   ,finish_(start + n)
{
   static if (!is_empty<A>::value) {
      alloc = alloc_;
   }
}

// Every access to the allocator member must be guarded by a new static if.
// Again, this use of static if is viral.
// A viable alternative to the use of static if or more traditional means of
// implementing the empty base optimization is to use a tuple. The tuple template
// will eliminate all of the overhead of empty classes.
// The use of static if might also be used to reorder data structures for tighter
// alignment, but this is a potentially dangerous idea that could lead to bugs that
// are exceptionally difficult to diagnose and fix.
// Being a new and relatively simple-to-use new feature, static_if would 
// undoubtedly be used by many who have no need for the relatively small 
// incremental improvement in performance offered. The library writers for which such
// techniques really are important, already have the tools and skills needed.

// The static if feature is also available inside class scope. A number of possible
// applications have been presented. Below is an example of a metafunction for
// computing factorials.

template <unsigned long n>
struct factorial {
   static if (n <= 1) {
      enum : unsigned long { value = 1 };
   } else {
      enum : unsigned long { value = factorial<n - 1>::value * n };
   }
};

// This seems like a reasonable idea, but the motivating example simply moves
// the complexity from one style of idiomatic programming to another and does
// so in a way that requires a new language feature. A better solution would be
// to use constexpr functions. A significant negative consequence of that feature
// is increased confusion about how to write integer metaprograms.