Problem with Swift Dictionary in C# / .NET

it does. from the error message, it sees the method, but doesn’t like the parameters. can you post your project or a testcase?

thanx,
marc

Sure, here it is.
Thanks for the quick reply.

ClassLibrary.zip (129.4 KB)

Just to give you some context as to why I’m still bringing up this issue, I managed to compile the project, but my results are returning empty, while running on Xcode they don’t, so I’m trying to figure out where the problem lies.

I found another issue:

public class Algorithms {
    
    public static func test() {
        var result = [Int: FundingOption]()
        
        print(result[1] == nil)
    }
    
}

this print should show true, but it’s showing false.
Any idea why?

thanks. ill have a look in the morning.

I think the problem is that reduce exerts a sequence (e.g., a list or something eumerable) as first parameter, but you’re passing a dictionary, which is not enumerable as such.

hmm. this standalone code prints True for me correctly:

import System.Collections.Generic
import System.Linq
import System.Text

public class FundingOption {
}

public static func test() {
	var result = [Int: FundingOption]()
	
	print(result[1] == nil)
}

test()

Or rather, reduce expects a sequence of the same type as the array you;re calling it on. a you call reduce on an array of FundingOptions, but pass a dictionary of Int/FundingOption.

reduce() is defined as public func reduce<U>(_ initial: U, combine: (U, T) -> U) -> U {.

(where U would be FundingOption in your case.

If I do
let result = reduce(fundingOptions, [Int: FundingOption]()) { result, fundingOption in ...
instead of
let result = reduce(fundingOptions, [Int: FundingOption](), { result, fundingOption in ...
it works, so I’m thinking it’s a small parsing issue on the compiler.

And no, the reduce method shouldn’t expect the initial parameter to be the same as the data it’s being called on.
U is a new type, hence it’s declared on the reduce<U>, and that’s the idea of reduce, to reduce / fold the array into another value (of completely different type).

As for the code, if you put that code inside my project, it doesn’t.
In fact, the IDE itself shows a green message saying that.

Also, if you change your code from class to struct, you can also see the same error without using the rest of the project.

1 Like

Hmm, both of those messages are curious. i’ll log an issue. can you send me the exact project that shows this so i can attach it as reproducible case for the compiler team?

Thanx, logged as 77921: Silver: odd warnings when using a dict of structs

this could be a side effect of how rulable structs work on .NET, WRT to the dictionary not returning a nullable (this the result of a dictionary access always is a non-null). but i’ll leave it to the compiler team to check the details.

You’re right; my bad.

hm, yeah. reproduced, and logged as 77924: Silver: closure rejected as parameter unless its trailing.

looks like its somehow mis-tying the closure, if its not trailing. strange.

Sending you the project.

ClassLibrary.zip (130.1 KB)

But to make their lives easier, all they need is this piece:

public struct Test {}

public class Algorithms {
    
	public static func test() {
		let result = [Int: Test]()

		print(result[1] == nil)
	}
    
}

actually, this makes sense (although the message could be more helpful, we’ll fix that). if the closure is not inline, you need tp provide the prefix for the parameter:

let result = reduce(fundingOptions, [Int: FundingOption](), combine: { result, fundingOption in ...

Wait, actually I created that reduce function, it’s not the .reduce.

But even with the default .reduce method, it doesn’t need the combine: on Xcode.

Hmm, i guess Apple renamed those again, then :(. I’ll check and adjust SwiftBaseLibrary to match. When we ported these and.or when i last checked, the prefix was combine:

—marc

Yup, they changed it again:

func reduce<Result>(_ initialResult: Result, _ nextPartialResult: (Result, Element) throws -> Result) rethrows -> Result

i’ve adjusted SBL to match, this will be in the next build, and is on GitHub now.

Thank you.

Let me know when there’s any update on the other issue.

Hi @mh it’s been 10 days, do you have any updates on that issue?
Thank you.

Well as i stated in my previous reply, it’s fixed in GitHub, and the next beta build will have the pre-compiled binary with the fix. There’s not much else to report/update?

Logged as bugs://i65257.