Native blocks not working?

[crmorello]

Is native being removed? I'm trying to inline an @objc modifier for just Swift. Looking at the code it looks like native isn't even visited when outputting Swift and a commit message from you yesterday said "remove native blocks".

They seem to work just fine in JavaScript and Java output. Swift just ignores them. Not that it matters, but if they were working it also appears that the @ in @objc causes a compile issue if it is in the native block. I would have thought anything in native would be ignored and just plopped into the output as-is.

Any ideas on a way to inline language/platform specific code?

[pfusik]

This feature is not going away. Yesterday's change was about removing uses of native from GenD.ci.

It works for Swift and there's a test for it:

C:\0\ci\git>cat test/StNative.ci
public static class Test
{
        public static bool Run()
        {
                int a;
                a = 1;
                native {a = 42;
                }
                return a == 42;
        }
}

C:\0\ci\git>make test/bin/StNative/swift.txt
test/bin/StNative/Test.swift
test/bin/StNative/swift.exe
test/bin/StNative/swift.txt

C:\0\ci\git>cat test/bin/StNative/Test.swift
// Generated automatically with "cito". Do not edit.

public class Test
{

        public static func run() -> Bool
        {
                var a : Int
                a = 1
                a = 42;
                return a == 42
        }
}

Could you show your code?

[crmorello]

#if SWIFT
native {
@objc
}
#endif
public class UnitConverter { ... }

Which results in a compiler error UnitConverter.ci(13): ERROR: Invalid character and is pointing to the @

If the native block is in a function scope it does appear to work, but I need it more for top-level. Right now I just create a wrapper for the transpiled swift so I can use it on the objc side, but it would be nice if I could add that decorator. I know it's a very specific use case though.

Looks like top-level native blocks don't generate for swift.

native {
    enum test {
        case a
    }
}

results in nothing in the swift output but it is added to Java/JavaScript.

[pfusik]

There were two issues:

• Top-level natives not emitted for Swift (and Python).
• The parser required the contents to be valid Ć tokens. The "@" character is not a valid Ć token, hence the error.

Fixed both. The latter with a new syntax:

native "@objc"

"git pull" cito and rebuild.

Top-level natives are meant for things such as imports and helper routines. That's why they are emitted at the top of the target file. This won't work if you have many classes.

[crmorello]

Thanks for looking into that and getting it fixed. This should be enough for my use case. I thought about outputting C or C++ and using it from Objective-C, but I wanted there to be one import in my project (a swift package) instead of two and I am trying to deprecate the Objective-C side anyways.

[crmorello]

Looks like this doesn't quite do what I expected. It does insert the native block in Swift, however it throws it at the import level which makes it useless in this context. I end up with this.
@objcimport Foundation

Toplevel native blocks that keep their position would be a nice feature. I can also see a use case for declaring specific data structures. For example it would be nice to be able to specify a struct for Swift instead of always having classes.

[pfusik]

Toplevel native blocks that keep their position would be a nice feature.

I'll do that.

I can also see a use case for declaring specific data structures.

You mean structs defined in Swift available to Ć code? I don't know how it could be done.

[crmorello]

Yeah after writing that I realized it wouldn't be easy. I guess actual struct support would be needed, but since not all targets support them there is not a great reason to have it.

I could see a decorator of sorts like this

@struct(swift)
public class Test { ... }

and then when it generates the output it uses a struct instead of class, it's a pretty specific use case and again is only useful in languages that support them in a similar manner to classes. You would also get into territory where the output could break depending on how your class is implemented.

I can manually alter the output so it's not a big deal. There are just some parts of the code where I would like to avoid a heap allocation.