# Why doesn't eg \`extension Array\<Int\> { ... }\` compile even though using a typealias does?

**URL:** <https://forums.swift.org/t/why-doesnt-eg-extension-array-int-compile-even-though-using-a-typealias-does/56049>\
**Category:** Using Swift\
**Tags:** generics, extensions\
**Created:** [March 18, 2022, 11:17pm UTC](https://forums.swift.org/t/why-doesnt-eg-extension-array-int-compile-even-though-using-a-typealias-does/56049 "2022-03-18T23:17:34Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jens](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jens/32/12903_2.png) [@Jens](https://forums.swift.org/u/Jens)\
**Post date:** [March 18, 2022, 11:17pm UTC](https://forums.swift.org/t/why-doesnt-eg-extension-array-int-compile-even-though-using-a-typealias-does/56049/1 "2022-03-18T23:17:35Z")

</div>

I'm still on Xcode 13.2.1 at the moment, so sorry if this question is outdated. Asking here after a quick fruitless search.

Here's an example of how I'm used to writing same type constrained extensions:

```swift
extension Array where Element == Int {
  var sum: Int { reduce(0, +) }
}

```

I happened to notice that this also works:

```swift
typealias ArrayOfInts = Array<Int>
extension ArrayOfInts {
  var sum: Int { reduce(0, +) }
}

```

So why these errors for:

```swift
extension Array<Int> { // ❌ Constrained extension must be declared on the unspecialized generic type 'Array' with constraints specified by a 'where' clause
  var sum: Int { reduce(0, +) } // ❌ Cannot convert value of type '(Int) -> Int' to expected argument type '(Int, Element) throws -> Int'
}

```

?

---

<div class="post-metadata">

**Author:** ![stackotter](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/stackotter/32/20670_2.png) [@stackotter](https://forums.swift.org/u/stackotter)\
**Post date:** [March 19, 2022, 12:00am UTC](https://forums.swift.org/t/why-doesnt-eg-extension-array-int-compile-even-though-using-a-typealias-does/56049/2 "2022-03-19T00:00:41Z")

</div>

The inconsistency you are facing is part of what is being discussed in the [lightweight same-type requirements for primary associated types thread](https://forums.swift.org/t/se-0346-lightweight-same-type-requirements-for-primary-associated-types/55869/5). It's not the main topic of discussion, however it was discussed at one point iirc. Sadly I cannot find back the posts explicitly mentioning that inconsistency.

---

<div class="post-metadata">

**Author:** ![Slava\_Pestov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/slava_pestov/32/30204_2.png) [@Slava\_Pestov](https://forums.swift.org/u/Slava_Pestov)\
**Post date:** [March 19, 2022, 2:18am UTC](https://forums.swift.org/t/why-doesnt-eg-extension-array-int-compile-even-though-using-a-typealias-does/56049/3 "2022-03-19T02:18:25Z")

</div>

It's an artificial restriction that can be lifted by passing the `-enable-experimental-bound-generic-extensions` frontend flag. It just needs a proposal.

---

<div class="post-metadata">

**Author:** ![hborla](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hborla/32/27563_2.png) [@hborla](https://forums.swift.org/u/hborla)\
**Post date:** [May 23, 2022, 5:50pm UTC](https://forums.swift.org/t/why-doesnt-eg-extension-array-int-compile-even-though-using-a-typealias-does/56049/4 "2022-05-23T17:50:36Z")

</div>

> [@Slava\_Pestov](#):
>
> It just needs a proposal.

Here you go!

> [@\[Pitch\] Extensions on bound generic types](https://forums.swift.org/t/pitch-extensions-on-bound-generic-types/57535):
>
> Hello, Swift Evolution! I've been working on a pitch for enabling extensions of bound generic types using angle-bracket syntax, e.g. extension Array\<String\> {}. This feature was subsetted out of the [original pitch for SE-0346](https://forums.swift.org/t/pitch-light-weight-same-type-constraint-syntax/52889). I've copied the current proposal draft below. Please let me know your questions, thoughts, and other constructive feedback! -Holly [Pitch] Extensions on bound generic types Proposal: [SE-NNNN](https://github.com/apple/swift-evolution/blob/5d86d57cfd6d803df4da90b196682d495e5de9b9/proposal-templates/NNNN-filename.md) Authors: Holly Borla Review Manager: TBD Status: Awaiting implementation I…

---

<div class="post-metadata">

**Author:** ![anon9791410](https://avatars.discourse-cdn.com/v4/letter/a/9fc348/32.png) [@anon9791410](https://forums.swift.org/u/anon9791410)\
**Post date:** [May 23, 2022, 8:40pm UTC](https://forums.swift.org/t/why-doesnt-eg-extension-array-int-compile-even-though-using-a-typealias-does/56049/5 "2022-05-23T20:40:04Z")

</div>

I like that pitch, except that it came before the long-existing underlying problem ever got fixed: if you want a property instead of a method or subscript, you either

1. [need to clutter the module with a typealias](https://stackoverflow.com/a/72121304/652038), as in this thread
2. or, [if you need constraints that reference an enclosing type, are out of luck](https://stackoverflow.com/a/66414926/652038).

The **Future directions** section is wonderful and would do a good job cloaking properties still being second-class, the way subscripts used to be.