Привет всем Начал изучать swift и застрял на opaque types.

Может кто то обяснить или дать хорошую ссылку?
Пишу на dart , go lang.

https://habr.com/ru/company/otus/blog/542080/ читал?

Да, но что то не понял в чем суть. Что то на интерфейс похоже

в каком смысле? Нет, это не имеет отношения к UI, просто в swiftUI метод body возвращает у вьюхи some View, но это языковая конструкция, так называемое стирание информации о типе

Я имел в веду протокол, он в других япах интерфейсом називается

а, всё всё, понял))

https://swiftbook.ru/content/languageguide/opaque-types/https://swiftbook.ru/content/languageguide/opaque-types/ и тут непонятно?

Тут нужно начать с понимания двух других вещей, это протоколы с ассоциативными значениями - PATs и экзистенциальные типы - Existentials. PATs - сильно упрощённо, это дженерик интерфейсы. Existentials - типы, которые могут выступать в качестве абстрактных типов И при этом являться полноценными типами. Обычные протоколы, не путать с PATs, являются экзистенциальными типами, тогда как PATs ими не являются. _ _ ___ Обычные протоколы являются и абстрактными типами и полноценными типами: protocol P { } func foo(_: P) ✅ class Class: P { } let p: P = Class() ✅ _ _ ___ PATs являются абстрактными типами, но не могут выступать в качестве полноценных типов, а могут служить лишь ограничениями protocol P { associatedtype A } func foo(_: P) ❌ func foo<T: P>(_: T) ✅ class Class: P { } let p: P = Class() ❌ protocol 'P' can only be used as a generic constraint because it has Self or associated type requirements. _ _ ___ С самого появления PATs в языке, будучи не Existentials типами, приходилось пользоваться такими конструкциями как Type Erasure, некий бокс, который мог содержать в себе PATs и работать в качестве полноценных типов. В стандартной библиотеке Swift таких боксов очень много: protocol Hashable - PAT struct AnyHashable - его Type Erasure protocol Collection - PAT struct AnyCollection<Element> - его Type Erasure и т.д. _ _ ___ А вот с приходом SwiftUI это проблема стала куда более острой уже для самих разработчиков языка. Конструкция Opaque Result Types отчасти пришла решить проблемы. Opaque Result Types - говоря просто, это обычный ревёрс дженерик. Если в дженериках, лишь вызывающая сторона знает конкретный тип, тогда как сама реализация его не знает. То в ревёрс дженериках всё наоборот, вызывающая сторона не знает конкретного типа, а реализия знает. На примере: Дженерики: func foo<T: P>(_: T) { // Мы не знаем конкретный тип T } foo<Class>(…) // А вот вызывающая сторона его знает. Реверс Дженерики: func foo() -> some P { // … return Class() // Теперь реализация знает конкретный тип } let p: P = foo() // Но вызывающая сторона не знает. _ _ ___ Opaque Result Types частично решают проблемы описанные в самом начале, они позволяют сделать PATs - экзистенциальными типами. То есть теперь та мы можем писать так: func foo() -> some Collection { … } class Class { var collection: some Collection { … } } НО на данном этапе у Opaque Result Types есть ограничения. Они не могут выступать в качестве аргументов для методов и функций и не могут быть использованы внутри протоколов и т.д. _ _ ___ Opaque Result Types решают также и проблему излишней verbosity, актуальной для SwiftUI. Тогда как в SwiftUI большая часть типов являются типами значений, то вместо наследования используется композиция. Что выливается обычно в нечто подобное: До: struct MyView: View { var body: A<B1, C1<D1, D2<E1, E2<…>>>> { // излишняя verbosity } } После: struct MyView: View { var body: some View { // излишняя verbosity исчезла } } _ _ ___ Opaque Result Types также позволяют скрывать внутренние типы реализация от посторонних глаз. func buttonBorderShape(_ shape: ButtonBorderShape) -> some View // какие там внутренние типы обертки используются и возвращаются нам неизвестно, мы знаем лишь о some View

Круто, спасибо большое за обяснение. Вы очень доходчиво все описали👍🏻👍🏻

👍