Compile error when map to normal type

Elements C#
1 
#if ECHOES
// Compile error: (E578) Cannot map to nullable type
public __mapped struct gint => Nullable<int> {
#elif COOPER
// Compile error: (E578) Cannot map to nullable type
public __mapped class gint => java.lang.Integer {
#elif NOUGAT
// ok
public __mapped struct gint => Foundation.NSInteger {
#endif
}

Elements 8.3.92.1905

This must be introduced by bugfix 73821

2

Just a reminder of this issue.

3

What’s the use case here? We explicitly disabled this the other day and discussed the argument in another thread.

also note that they’re not the same. the last one is a plain integer of variable size, the rest is nullable.

4

  1. I’m confused…In my discussion with marc (Mapped class to wrapped value types can’t work as expected), the mapping to int? is disabled because marc thinks nullable is a modifier instead of a specific type.
    But here Nullable and java.lang.Integer are specific types.

  2. I’ve also explained the use case in my origin post:
    Mapped class to wrapped value types can’t work as expected

5

There’s no comments anymore…?

For mapping class mechanism, there’s no difference between java.lang.Integer and java.lang.Object, so why the former one should be disabled? “Nullable” is misunderstood here. Please just refer to bug 73822(Mapped class to wrapped value types can’t work as expected), it will make things clear.
I hope for a rollback of bugfix 73821 if there’s no quick fix for this issue.

On 8.3.92.1901, I can still write more implicit operators to avoid mapping class errors. But after bugfix 73821, I can’t do that:
(Compile error when map to normal type)
(Can’t define implicit conversion)

But I can’t just stay on 8.3.92.1901, because this issue is unresolved:
(Incorrect base method calling cause StackOverflow on Android)

Ultimately my cross-platform frameworks work has been stuck for nearly a month on these generic programming issues.
I’ve seen lots of bugfixes for Silver in recent multiple betas, but nearly nothing for problems in RO C#. I don’t think I should pay another $799 to get this.

6

Thanks, logged as bugs://74178

7

I apologize for this. The errors you are seeing now seem to be a regression/side-effect from the original fix. I agree that this code you have now should compile ok, for all three platforms, as you are mapping to regular types (which just “happen” to be the types used internally to represent nullable Ints).

We’ll look at getting this fixed ASAP, well in time of your current subscription period. I have also taken the liberty and extended your subscription by an extra 3 months to make up for the inconvenience — does that sound fair?

yours,
marc

8

Yes the compensation sounds fair, but I’m also looking forward to higher priority for RO C# and cross-platform capability issues:

  1. I know Silver is immature but free so there are many new users and feedbacks, which is your current focus. But RO C# is not free (I bet if it’s free, it won’t be less popular than Silver) and targets high-quality users that may contribute more valuable feedbacks in their serious development and demonstrate the potential of Elements in their business products.
    Now I don’t make any complaint about the Elements VS plugin (like CC, formatter issues etc), because althought it’s actually terrible (many error prompts when I do simple coding in VS daily), I think it’s trivial (I almost do all coding work related to Elements in SublimeText). I won’t report issues about EUnit, because I’ve built my own cross-platform unit test library to replace it after EUnit was broken for iOS months ago. The only things I care are compiler and debugger.
    I think I’m one of the typical users who are truely willing to pay money to buy Elements instead of just playing it freely.

  2. Elements is really potential and distinguishing from other cross-platform solutions. That’s why I don’t give Xamarin/RoboVM things a chance. But I’m also sure that there’s no enough practice in complex business product for Elements.
    I choose Elements to implement a cross-platform framework, under which I can write same clean codes for different platforms even including UI. I think my objective is also the ultimate objective of Elements. Then I’ve found many practical issues that can’t be ignored:

2.1) __weak for ARC can’t be ignored for GC platform by default, which is really easy to do for compiler I think. The Cross-platform compatibility you recommended will bring many strange warnings and known and unknown side-effects which is too risky for me.
Are Cocoa Storage Modifiers ignorable on other platforms?)

2.2) Element’s ARC still can’t perform the same optimization as Objc’s compiler for iOS. Cross-platform codes can’t depend on explicit ARP to improve the performance, which will make your codes awkful.
Question about Element’s ARC)

2.3) There’s no elegant solution for value types in generic programming by default. Just try to write a reusable comparer function to sort your cross-platform List<int>, and you will get my point.
Mapped class to wrapped value types can’t work as expected)

These cross-platform capability issues are generic for all users and unable to avoid in serious cross-platform development, so they are more urgent to be fixed than minor bugs in specific language.

1 Like
9

bugs://74178 got closed with status fixed.

10

So the mapped on nullable stuff works now for the next build. Do consider it a “beta” feature, bug reports appreciated on it.