Swift Type(of:) function no worky

Elements Fire
1

Good afternoon,
Continuing my journey of the Swift programming language. Supposedly it’s very Swifty to divide a function name among argument labels. One example is typeOf in C# vs type(of:) in Swift. Unfortunately, Fire returned an error: Unknown identifier. Thanks for taking a look :slight_smile:

Screen Shot 2021-05-10 at 2.13.31 PM
Screen Shot 2021-05-10 at 2.13.31 PM2656×934 190 KB

2

Hmm, that’s new? last I recall “.Self” was the equivalent of typeOf()…

I’ll log an issue to have this added, compiler side.

3

Thanks, logged as bugs://85902

4

Thanks for checking on it Marc. I think it’s interesting how Swift promotes dividing the function name with parameter names such as:

Swift//
show(message: ) 
C#//
showMessage()

Another example from Simon Allardice, a very good lecturer on Pluralsight:

Screen Shot 2021-05-10 at 3.29.02 PM
Screen Shot 2021-05-10 at 3.29.02 PM2068×776 146 KB

5

You got me looking up .self vs type(of:) … what a metatype rabbit hole :D. In short, type(of:) Dynamic Metatypes vs .self Static Metatypes.

6

Fixed for Fridays build, and in GitHub.

yeah,. its (IMHO) a bastardiez version of Ovjective-Cs='s very nice and descriptive multi-part selector/method names…

yeah. it still confuses me every time, too :wink:

1 Like
7

just a quick heads up … it appears ‘type(of:)’ is still generating an ‘Unknown identifier’ error with the latest build .2629 :thinking:

8

My apologies; it looks like i forgot to merge. Done for next week, or you can grab SBL from GitHub yourself: GitHub - remobjects/SwiftBaseLibrary.

yours,
marc

1 Like
9

Just a quick note to say that type(of:) works now with the latest version of Fire. :fist_right: :fist_left:

As a side note, looking forward to your Webassembly webinar with Jim McKeeth next week. I’d have to agree with the ‘other’ Hoffman (Kevin) that Webassembly’ is such a misnomer. :nerd_face:

10

I may have spoken too soon. :expressionless: It appears Elements’ type(of:) lacks the specificity of Swift in distinguishing an int vs double datatype. Also, Elements returns a (null) for a String datatype. :no_mouth: Happy Monday! :nerd_face:

Screen Shot 2021-05-22 at 5.04.37 PM
Screen Shot 2021-05-22 at 5.04.37 PM2298×1086 294 KB

11

Ah yes, the Int/Doubke make sense, as these get boxed tote passed to the function :(. we might need to move this into he compiler, after all. The String issue is a stranger…

The variance never read warnings seem wrong too…

1 Like
12

Thanks, logged as bugs://85967

13

Curious. This works:

~> Process ConsoleApplication167 started, took 0.213.
__NSCFConstantString
hello
~> Process ConsoleApplication167 terminated with exit code 0. Ran for 1.964

for:

import Foundation;
do {
    let sv : String = "";
    print(type(of: sv));
    print("hello");
}

can I get the full sample?

14

bugs://85902 got closed with status duplicate.

15

Hi Carlo,

I confirm that the above code works here as well. Here’s an iCloud link to my file. Let me know if the link works. Cheers.

Swift Type(of:) File

Here’s an alternate Dropbox link:

16

bugs://85967 got closed with status fixed.

1 Like
17

Thank you for the latest build y’all :slight_smile:

@ck, I noticed that your code is wrapped in a do statement - mine was not. Once I wrapped my code in a do statement, it functioned properly in the latest Fire release .2633.

Screen Shot 2021-05-30 at 9.16.28 PM
Screen Shot 2021-05-30 at 9.16.28 PM1320×584 139 KB

The optional Swift do statement appears to be the equivalent of non-optional braces in C languages as well as Begin, End in the Pascal languages, so it’s understandable that the do statement may be necessary for compatibility reasons - Elements being the ‘polyglot’ compiler par excellence. :nerd_face::+1:

18

Fridays build should also support your testcase

1 Like