Using the phrase "Speed of Light" is such a misnomer I believe it actively causes harm and makes some things in physics more difficult to understand than they otherwise would be. Why should light's chosen speed have anything to do with, well, anything at all? Why should time travel being impossible be related to light? Why should our ability to travel have anything to do with light? Why should time dilation give a fig about light?

The answer is none of those have anything to do with light or its speed. Whatsoever. Our universe has a speed of causality. The maximum speed at which changes in the fields that make up our spacetime can propagate from one quanta, one point, of spacetime to another. This is a physical property of the universe itself. Putting everything else aside if light did not exist all of those other effects would remain unchanged. The maximum speed anything with mass could travel would not change. The need to adjust the clocks of GPS satellites due to time dilation in a gravitation field would not change. Light has nothing to do with it.

Light travels at a maximum speed because having no mass the laws of physics require it to do so. Light speed is a side effect. It is not the cause or source of the things attributed to it.

I don't know if Speed of Causality is the right phrasing but we need a better one. Quantum physics is brain-breaking enough, no need to go confusing the matter by inferring that the speed at which light travels is the cause of other phenomena.

A further aside

All metaphors, analogies, and simplifications are by necessity imperfect. Most people cannot understand anything without first grasping a simplified version of it (I certainly cannot). A proverbial hook on which to hang one's mental hat. The more abstract the concept the more concrete the path to understanding needs be.

Imagine our universe - our spacetime - is made up of an uncountable number of tiny quanta or points. There is no such thing as "between" these points. They are existence itself. Imagine further that each point can only transmit or receive changes in fields from its immediate neighbors at certain defined steps in time. In other words the clock ticks, everyone exchanges changes like white elephant gifts, then sits back down to process what they've got and plan the next move. None of them can take or hand over anything until the next clock tick.

Thought of this way it makes complete sense there should be some maximum speed during which the current point applies the rules and the results are propagated to its neighbors during the next step. The total time it takes for these ticks to happen over some distance is the speed of causality over that distance. The maximum speed at which each neighbor can hand things to the next neighbor in a long bucket brigade.

Now does our universe actually work this way? I have no idea. Probably not. It is just an analogy. Hopefully someone with greater understanding will come up with a better one.

The first is the ability to control interpolation into a custom type that adopts ExpressibleByStringInterpolation. This allows you to create types like HTML and drives the new OSLog string formatting (eg log.debug("value \(x, privacy: .public)"). Becca Royal-Gordon provided some nice examples of this in the SE-0228 proposal.

As a side-effect String and Substring now use DefaultStringInterpolation giving us a convenient extension point to customize interpolation behavior.

DefaultStringInterpolation

As an example let's say we want to represent file URLs as paths without the file:// prefix. We can accomplish this easily:

extension DefaultStringInterpolation {
    fileprivate mutating func appendInterpolation(_ url: URL) {
        if url.isFileURL {
            appendInterpolation(url.path)
        } else {
            // Careful, passing `url` here creates
            // an eternal loop that smashes the stack
            appendInterpolation(url.description)
        }
    }
}

let u = URL(fileURLWithPath: "/private", isDirectory: true)
print("\(u)") //prints "/private" instead of "file:///private"

A good practice is to ensure that all paths in your appendInterpolation method ultimately pass a StringProtocol type onward to avoid accidental eternal loops or ensure your first parameter is named so your method is not chosen as a default overload.For framework authors you should consider any public DefaultStringInterpolation extensions very carefully.

For another example assume we'd like to have a convenient way to format integers:

enum IntegerStyle {
    case decimal
    case hexadecimal
    case octal
}

fileprivate enum BinaryIntegerCategory { case signed, unsigned }

fileprivate extension BinaryInteger {
    var interpolationValue: (BinaryIntegerCategory, UInt64) {
        return (self is any SignedInteger) ? 
            (.signed, UInt64(bitPattern: Int64(self))) : 
            (.unsigned, UInt64(self))
    }
}

extension DefaultStringInterpolation {
    mutating func appendInterpolation<Value: BinaryInteger>(
        _ value: Value, 
        style: IntegerStyle
    ) {
        let (category, value) = value.interpolationValue
        switch style {
            case .decimal where category == .signed:
                appendInterpolation(String(format: "%lld", value))
            case .decimal:
                appendInterpolation(String(format: "%llu", value))
            case .hexadecimal:
                appendInterpolation(String(format: "0x%llx", value))
            case .octal:
                appendInterpolation(String(format: "0o%llo", value))
        }
    }
}

Values are promoted to 64-bit so our value is a CVarArg and we only need one size prefix in our format string. Signed decimal is the only special case but we only need to use the correct format character. All integer values are promoted to 64-bit when passed as varargs anyway and the underlying printf library will interpret those 64-bits entirely based on the argument length modifier and conversion specifier.

This example could be further extended to support floats, alignment, minimum widths, and various other features of printf-style formatting.