bare navbar-expand incorrectly removes padding for all widths

Created by: agriffis

There's a bug in the loop that generates navbar-expand, resulting in removing container padding for all viewport widths. Here is the live jsbin: https://jsbin.com/tuhugu/edit?html,output

I understand the purpose of removing padding. This report is not about that. Rather there's a specific bug in the scss loop that causes navbar-expand to remove padding where it shouldn't, while navbar-expand-sm and similar work as intended.

How it's intended to work:

When the container is within your navbar, its horizontal padding is removed at breakpoints lower than your specified .navbar-expand{-sm|-md|-lg|-xl} class. This ensures we’re not doubling up on padding unnecessarily on lower viewports when your navbar is collapsed.

The navbar-expand class is synonymous with the fictional navbar-expand-xs, meaning that it should remove horizontal padding at breakpoints lower than 0px. Of course there are no such breakpoints, so it shouldn't remove padding anywhere. Instead it removes padding everywhere, as you can see in the jsbin linked above.

The bug is in the loop here

// Generate series of `.navbar-expand-*` responsive classes for configuring
// where your navbar collapses.
.navbar-expand {
  @each $breakpoint in map-keys($grid-breakpoints) {
    $next: breakpoint-next($breakpoint, $grid-breakpoints);
    $infix: breakpoint-infix($next, $grid-breakpoints);

    &#{$infix} {
      @include media-breakpoint-down($breakpoint) {
        > .container,
        > .container-fluid {
          padding-right: 0;
          padding-left: 0;
        }
      }

In this loop, there is a relationship: $next should always be the breakpoint immediately larger than $breakpoint

However this breaks (no pun intended) when $breakpoint = "xl" -- in that case there is no larger breakpoint, so $next = null and $infix = ""

The result is this unintended css:

.navbar-expand > .container,
.navbar-expand > .container-fluid {
    padding-right: 0px;
    padding-left: 0px;
}

There are some similar reports, but #22471 (closed) is closed and I'm not sure #24726 (closed) is exactly the same.