编译器无法对此表达式swift 4进行类型检查?


75

更新xCode后,我将此错误输入我的代码中:

编译器无法在合理的时间内对这个表达式进行类型检查。尝试将表达式分解为不同的子表达式

编码 :

//check popup in window frame

let spaceFromLeftSide = cutOutViewX.constant + cutOutViewWidth.constant/2 - (options.textWidth + padding*2)/2

if spaceFromLeftSide < 0{

    if options.side == .bottom {
        messageRightSpaceFromBottomDot.constant -= spaceFromLeftSide - padding
    }
    else if options.side == .top{
        messageRightSpaceFromTopDot.constant += spaceFromLeftSide - padding
    }
}

let spaceFromRightSide = cutOutViewX.constant + cutOutViewWidth.constant/2 + (options.textWidth + padding*2)/2

if spaceFromRightSide > targetView.frame.size.width{

    if options.side == .bottom {
        messageRightSpaceFromBottomDot.constant -= spaceFromRightSide - ( targetView.frame.size.width )
    }
    else if options.side == .top{
        messageRightSpaceFromTopDot.constant += spaceFromRightSide - ( targetView.frame.size.width )
    }
}

发生错误:

let spaceFromRightSide = cutOutViewX.constant + cutOutViewWidth.constant/2 + (options.textWidth + padding*2)/2

如何解决呢?


该代码中是否有任何值是计算得出的值?例如options.textWidth?您可以尝试为每个变量指定类,而不是依赖于类型推断。例如let spaceFromLeftSide: CGFloat =
Ashley Mills

1
发生这种情况时,名为SourceKitService的进程在我的8GB计算机上使用了超过13GB的内存。通常,它使用300MB以上的内存。看起来,某些表达式会在构建过程中造成内存泄漏。
Gerd Castan '18

3
我不得不承认当我看到这个错误时我已经翻了个白眼
Brad Thomas

这是另一个荒谬的示例:return
user33775 '19

释放内存,错误消失!:)
Gope

Answers:


89

编译器无法在合理的时间内对这个表达式进行类型检查。尝试将表达式分解为不同的子表达式

快速编译器发现表达式计算过长时,将出现此错误。欲了解更多详情,请点击这里

要解决此问题,您只需要将表情分成较小的部分即可。就像:

let cutOutxOrigin = 3 * cutOutViewX.constant / 2
let actualPadding = (options.textWidth + padding * 2) / 2

let spaceFromRightSide = cutOutxOrigin + actualPadding

我以前见过这个,但不明白为什么,最终使代码更简单。这个答案很清楚。谢谢。
beshio

76
工作了!我每天都越来越讨厌XCode ...糟糕的IDE!
Pelanes

5
@Pelanes我不是在这里捍卫XCode,但这不是由IDE而是由编译器引起的……
Greg Hilston

69
我也看到了此编译器错误,作为开发人员30多年,这很可笑。因此,在2019年,我们作为开发人员的工作是...不要使编译器工作太辛苦?超过半个世纪以来,编译器一直在解析表达式,远不止于此。这是通过错误的编译器错误来强制执行编码样式。

27
我是一位经验丰富的C#和Java开发人员,并且正在从事Swift开发...而我刚遇到这个问题。认真吗 我只是使用print(“我的值是” + self.something1 +“,” + ... +“,” + self.something6)。那对于编译器来说太多了吗?我在c#中吐出了100个变量的列表,编译器甚至都没有眨眼。这是一种语言的玩笑。
jo phul

11

我在不同的情况下遇到了类似的问题

我试图创建字符串数组

let selectedData = [
        (data?.nose?.stuffyNose) ?? "",
        (data?.nose?.sinusProblems) ?? "",
        (data?.nose?.hayFever) ?? "",
        (data?.nose?.sneezingAttacks) ?? "",
        (data?.nose?.excessiveMucusFormation) ?? ""
] 

我已经添加了括号(), 但仍无法正常工作。


为了解决这个问题,我添加了类型 [String]

let selectedData:[String] = [
        (data?.nose?.stuffyNose) ?? "",
        (data?.nose?.sinusProblems) ?? "",
        (data?.nose?.hayFever) ?? "",
        (data?.nose?.sneezingAttacks) ?? "",
        (data?.nose?.excessiveMucusFormation) ?? ""
] 

希望对遇到同样问题的人有所帮助


9

只需尝试将表达式分解为几个更简单的子表达式即可。例如:

let halfOfViewWidth = cutOutViewWidth.constant / 2
let textWidthAndPadding = options.textWidth + (padding * 2)
let spaceFromRightSide = cutOutViewX.constant + halfOfViewWidth + (textWidthAndPadding / 2)

编辑

我注意到,我是能够通过提供显式类型转换来解决这种类型的错误(例如,而不是依靠编译器来推断乘以一个CGFloatInt它应该产生CGFloat,我已经明确地转换的IntCGFloat)。看来问题确实出在类型以及类型自动推断和检查上。尽管将复杂的表达式分解成较小的部分对于提高可读性非常有用,但是您可以通过明确地说明类型来解决问题(错误消息基本上表明编译器无法进行类型检查-因此,您可以通过尽可能提供明确的类型)。


3

所以我有这种表达:

return (50 + textHeight) + (dateTextHeight + 16) + (5 + 8) + (16 + 20)

我知道我必须分解或使该表达式更短才能摆脱错误。也许:

return (50 + textHeight) + (dateTextHeight + 16) + 49

尽管它足够真实,可以帮助编译器完成工作,但导致错误的主要原因是可选的Int textHeight。我认为无论您的表达多长时间,它都应该是可编译的。


3

当我不小心将表达式中的可选内容混合时,出现了此错误。强制展开后,错误消失了。

let a : String = "A" 
let b : String = "B" 
let c = letterDictionary["C"]

let imageName : String = a + b + c //error 
let imageName : String = a + b + c! //no error 

谢谢。这确实掩盖了潜在的错误。在我的情况下,尝试迭代自协议。
德克·贝斯特

2

在使用SwiftUI时,我经常会看到此问题,这始终是语法错误的结果。我当前正在使用Xcode 11.4.1,对于支持SwiftUI的早期版本来说确实如此。

例如,由于该错误,我刚刚刻录了50分钟,因为我在另一个文件中更改了函数参数的名称。编译器在一个完全未修改的SwiftUI文件中报告了此错误,除了它在不更改参数名称的情况下调用了该函数。与其明确指出参数名称不匹配,是因为此错误。


1

编译器混淆时,会发生此错误。我碰到它做了冗长的计算,混合了各种数字类型

我能够通过将各种子计算转换为CGFloat来对此进行补救。我不需要按照某些答案的建议“分解”表达式。

  • 来自:(一些浮点表达式)* someDouble / someInt
  • To:(一些float表达式)* CGFloat(someDouble / someInt)

0

这确实是一个内存问题。当我在16GB的计算机上只有350 mb的可用内存时,这件事发生在我身上。使用fe CleanMyMac->释放内存可以解决此问题。


1
不是内存问题。该错误在具有24GB可用内存的计算机上可重现
Ckacmaster

您确定xCode进程即使可以使用也可以分配更多的内存吗?通常每个进程的堆大小和堆栈大小都有限制。
Gope

释放内存为我工作。清除错误后,可用内存为32 Gb的1.2,即干净的32 Gb构建成功的13.29
ilker

0

通过简单地这样做:

    let array = [Int]()
    let dic   = [Int : Double]()
    
    let tuple = array.map { c -> (a: Int, b: Double) in return (a: c, b: dic[c]!) }.sorted(by: { (first, second) -> Bool in return first.b == second.b ? first.a < second.a : first.b > second.b }).first!

Xcode 11.6需要10秒的Cpu,4个进程以100%的速度运行,在MacPro 2019上消耗了很多瓦特,我得到了错误消息:不同的子表达式)

即使只有地图和某种组合!

如果我一分为二:

let temporaryTupleArrayToAvoidTheCompilerBug = array.map { c -> (a: Int, b: Double) in return (a: c, b: dic[c]!) }

let tuple = temporaryTupleArrayToAvoidTheCompilerBug.sorted(by: { (first, second) -> Bool in return first.b == second.b ? first.a < second.a : first.b > second.b }).first!

有用。

错误消息在这里隐藏了一个错误,编译器可以拆分指令并分别检查方法的语法。


0

这发生在我身上。我将两个传递Float给一个SwiftUI结构,并从另一个内部减去一个,但是错误地将Float内部定义为Dates(该死,复制粘贴!)。

基本上就是这个。

struct Something: View {
    var minValue: Date
    var maxValue: Date

    var body: some View {
        let valueDifference = maxValue - minValue
    }
}

我这样称呼它:

let minValue: Float = 0
let maxValue: Float = 1

Something(minValue: minValue, maxValue: maxValue)

注意,我实际上传递了两个Float,但是结构将接受它们,即使它们被定义为Date

我将Date类型更改Float为问题后,问题就消失了。


0

我有一个表达式,该表达式具有可选变量的几种用法,具有备用值,如下所示:

if ((self.scrollView?.contentSize.width ?? 0.0) > 0.0) && ((self.scrollView?.contentSize.height ?? 0.0) > 0.0) && ((self.scrollView?.frame.size.height ?? 0.0) > 0.0) {

复制变量的非可选副本时,错误消失了:

guard let scrollView = self.scrollView else { return }
if (scrollView.contentSize.width > 0.0) && (scrollView.contentSize.height > 0.0) && (scrollView.frame.size.height > 0.0) {

根据可选变量为nil时要执行的操作,此单行版本也可能有用:

if let scrollView = self.scrollView, (scrollView.contentSize.width > 0.0), (scrollView.contentSize.height > 0.0), (scrollView.frame.size.height > 0.0) {

-3

我遇到了错误,因为我将枚举与字符串拼接在一起。

例如:

let url = "/api/" + type

type是一个枚举类型。我用

let url = "/api/" + type.rawValue
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.