# Fixing Angle Bracket Blindness (and unboxing existentials while we're at it...)

**URL:** <https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223>\
**Category:** Pitches\
**Tags:** generics, existential\
**Created:** [March 25, 2022, 10:35am UTC](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223 "2022-03-25T10:35:25Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![jeremyabannister](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeremyabannister/32/10143_2.png) [@jeremyabannister](https://forums.swift.org/u/jeremyabannister)\
**Post date:** [March 25, 2022, 10:35am UTC](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223/1 "2022-03-25T10:35:25Z")

</div>

Here's the idea:

## Proposed New Syntax

```swift
func doSomething (with value: <Value>)

```

is less blinding than:

```swift
// Current blinding syntax
func doSomething <Value> (with value: Value)

```

## Allows Constraints

```swift
func first (of collection: <C: Collection>) -> C.Element

```

## Angle Brackets Must Appear On First Usage

```swift
func assign (_ newValue: <Value>, to destination: inout Value)

```

## Works With Associated Types

```swift
func feed (_ food: <Recipient: Eater>.Food, to recipient: Recipient) -> Recipient.FormOfThanks

```

## Allows Generic Computed Properties

```swift
var anyKindOfSevenYouWant: <T: ExpressibleByIntegerLiteral> {
    .init(integerLiteral: 7)
}

```

## Works With Local Variables

```swift
let foo: <T> = 7

```

desugars to:

```swift
typealias T = Int
let foo = 7

```

thereby allowing:

```swift
let maximumInteger = T.max // This is `Int.max`

```

## Unboxing Existentials

```swift
let boxedUpValue: some Equatable = ...
let value: <Value> = boxedUpValue
if let dynamicallyCasted = someOtherValue as? Value {
    print(value == dynamicallyCasted)
}

```

## Extensions On Any

```swift
extension <T> {
    func mutated (by mutation: (inout Self)->()) -> Self {
        var copy = self
        mutation(&copy)
        return copy
    }
}

```

I proposed this a while ago with many more words and with a few differences. In this post I've incorporated a few of the main pieces of feedback from the [original post](https://forums.swift.org/t/a-new-idea-about-generics/49251) and I've skipped all of the description because the syntax mostly speaks for itself. Let me know what you think!

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [March 25, 2022, 3:09pm UTC](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223/2 "2022-03-25T15:09:34Z")

</div>

There’s already an idea that `some P` in argument position will alleviate the need for angle brackets on cases where type parameters don’t need to be named:

```swift
func doSomething(with value: some Any)

```

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 25, 2022, 5:25pm UTC](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223/3 "2022-03-25T17:25:35Z")

</div>

> [@jeremyabannister](#):
>
> Here's the idea:

A couple of these overlap significantly with other ideas that have been recently discussed, so I'll point those out here.

> [@jeremyabannister](#):
>
> `func doSomething (with value: <Value>)`

As Kyle [noted](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223/2), this use case is subsumed by opaque parameters, a Swift 5.7 feature that was recently accepted and implemented as [SE-0341](https://github.com/apple/swift-evolution/blob/main/proposals/0341-opaque-parameters.md). This example would be written as:

```swift
func doSomething(with value: some Any)

```

> [@jeremyabannister](#):
>
> ## Allows Constraints
> 
> ```swift
> func first (of collection: <C: Collection>) -> C.Element
> 
> ```

[SE-0326](https://github.com/apple/swift-evolution/blob/main/proposals/0346-light-weight-same-type-syntax.md), which is under active review right now, composes with SE-0341 to allow one to specify, e.g., the element type of generic collections. Your example doesn't translate precisely, but it's very much in the same space. I do think it makes the case for your suggested syntax a much harder sell, because it's eliminating the angle brackets entirely in a subset of the use cases.

> [@jeremyabannister](#):
>
> ## Allows Generic Computed Properties
> 
> ```swift
> var anyKindOfSevenYouWant: <T: ExpressibleByIntegerLiteral> {
> .init(integerLiteral: 7)
> }
> 
> ```

I think generic computed properties would be a good feature on its own, and is orthogonal to the syntax you describe.

> [@jeremyabannister](#):
>
> ```swift
> let boxedUpValue: some Equatable = ...
> let value: <Value> = boxedUpValue
> if let dynamicallyCasted = someOtherValue as? Value {
> print(value == dynamicallyCasted)
> }
> 
> ```

There's an active pitch on [implicitly opening existentials](https://forums.swift.org/t/pitch-implicitly-opening-existentials/55412) that's in the same spirit as this.

> [@jeremyabannister](#):
>
> ## Extensions On Any
> 
> ```swift
> extension <T> {
> func mutated (by mutation: (inout Self)->()) -> Self {
> var copy = self
> mutation(&copy)
> return copy
> }
> }
> 
> ```

Another separable and good feature, which we often call "parameterized extensions".

Doug

---

<div class="post-metadata">

**Author:** ![jeremyabannister](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jeremyabannister/32/10143_2.png) [@jeremyabannister](https://forums.swift.org/u/jeremyabannister)\
**Post date:** [March 26, 2022, 11:55am UTC](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223/4 "2022-03-26T11:55:27Z")

</div>

@Douglas_Gregor Thanks for the thorough consideration, much appreciated. The idea actually originally came to me because I was considering how we might spell the unboxing of existentials, and I hit upon this syntax:

```swift
func receivesExistential (_ existential: any Equatable) {
    let unboxed: <Value> = existential
    // `Value` is now the local name of the dynamic type contained within the existential.
    // and `unboxed` is the existential value with its type now known and named.
}

```

After thinking of this syntax I pondered _why_ it seemed like a natural spelling to me, and that led me to think about what such a syntax would logically mean if it were used in other situations where a type name is expected, for example in function arguments:

```swift
func doSomething (with value: <Value>)

```

or as the type being extended:

```swift
extension <T> {

}

```

and I realized that almost no matter where I used it it yielded either an improved method of doing something that's already possible or the ability to do something previous not possible.

With that being said, I have two concrete questions:

1. Do you think that there's an argument to be made that there's value in having a single unifying syntax for all of the features I described, even though it is also possible to build them all separately?

2. In my somewhat quick read of the new existential-unboxing feature that you mentioned it seemed to me that it would not be possible to write this function:

```swift
static func == (lhs: any Equatable, rhs: Any) -> Bool {
    let unboxedLHS: <LHS> = lhs
    if let dynamicallyCastedRHS = rhs as? LHS {
        return unboxedLHS == dynamicallyCastedRHS
    } else {
        return false
    }
}

```

Am I correct that this would not be possible?

Thanks Doug!

---

<div class="post-metadata">

**Author:** ![xwu](https://avatars.discourse-cdn.com/v4/letter/x/b487fb/32.png) [@xwu](https://forums.swift.org/u/xwu)\
**Post date:** [March 26, 2022, 12:36pm UTC](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223/5 "2022-03-26T12:36:04Z")

</div>

> [@jeremyabannister](#):
>
> 1. In my somewhat quick read of the new existential-unboxing feature that you mentioned it seemed to me that it would not be possible to write this function:
> 
> ```swift
> static func == (lhs: any Equatable, rhs: Any) -> Bool {
> let unboxedLHS: <LHS> = lhs
> if let dynamicallyCastedRHS = rhs as? LHS {
> return unboxedLHS == dynamicallyCastedRHS
> } else {
> return false
> }
> }
> 
> ```
> 
> Am I correct that this would not be possible?

It's possible. You’re correct to point out that one could not refer to the opened type of `lhs` by name. At first glance this may seem like a big deal, but in fact it’s not an issue:

To preserve the signature verbatim, you'd use two functions:

```swift
/* static can't be declared outside a type */
func == (lhs: any Equatable, rhs: Any) -> Bool {
  _equals(lhs as some Equatable, Any) // (1)
}

func _equals<T: Equatable>(lhs: T, rhs: Any) -> Bool {
  if let rhs = rhs as? T {
    return lhs == rhs
  } else {
    return false // Probably not wise, but we're not here to discuss that.
  }
}

```

Now, you'll notice that Doug has proposed _implicit_ existential opening, so in fact any arguments that can be passed to `==` can be passed to `_equals` without explicitly opening the existential first (shown at 1), making the entirety of the outer wrapper function redundant. In other words, if you're not under ABI stability constraints, you don't need to go through this trampoline at all and can just write:

```swift
func == <T: Equatable>(lhs: T, rhs: Any) -> Bool {
  if let rhs = rhs as? T {
    return lhs == rhs
  } else {
    return false // Still probably not wise, but we'll move on.
  }
}

```

Notice that not only is this very straightforward to write, it's a function that you can write already; Doug's proposed solution would make it Just Work to pass an existential box as the first argument. So in fact the genius of Doug's proposed solution is that it makes what you're asking for not just _possible_ but also simultaneously _unnecessary_. Nice.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 31, 2022, 12:27am UTC](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223/6 "2022-03-31T00:27:44Z")

</div>

> [@jeremyabannister](#):
>
> Do you think that there's an argument to be made that there's value in having a single unifying syntax for all of the features I described, even though it is also possible to build them all separately?

Abstractly, I could agree to the argument that it's useful to express some of these ideas. Concretely, we already have two levels of syntax for describing parameterization---generic parameter lists and `some`---and adding a third doesn't automatically mean there's more expressiveness. What I see here are a few different features that could be expressed using the syntactic ingredients we already have. The missing piece is to design how these features work, without focusing on the syntax.

> [@jeremyabannister](#):
>
> In my somewhat quick read of the new existential-unboxing feature that you mentioned it seemed to me that it would not be possible to write this function:

Xiaodi [answered this](https://forums.swift.org/t/fixing-angle-bracket-blindness-and-unboxing-existentials-while-were-at-it/56223/5) splendidly.

Doug