So I have a usecase for macros in Kotlin. I want ...

# language-proposals

[jkbbwr]

So I have a usecase for macros in Kotlin.
I want to do lots of unsigned type work. I know the JVM doesn't have unsigned types but manually keeping track of the shifting and types might introduce bugs.
If I had macros I could generate it at compile time.

[benleggiero]

What kind of macros (I assume you mean “compiler macros” like #define. I call these “preprocessor directives”)?

I approve of Swift’s use of a very minimal and strict set of these, mainly just for querying the targeted platform.
Further reading: https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/doc/uid/TP40014097-CH33-ID539

I’d be all for using this approach in Kotlin. Perhaps something like

#if platform(JVM)
...
#elseif platform(native.Windows)
...
#elseif platform(native.macOS)
...
#elseif platform(native)
...
#elseif platform(JS)
...
#else
...
#endif

and

#if kotlin(>=1.1)
...
#else
...
#endif

[gildor]

Conditional macros looks like really bad solution for me. actual/expect approach much better imo. All those platform specific stuff mixed in a single file is a huge mess for me, hate it in any C++ code that I see. Looks like lack of good app architecture

[jkbbwr]

@gildor Im not talking about conditional macros im talking about wrapping boilerplate in compile time evaulation

[gildor]

@jkbbwr My comment is about @benleggiero message, not about your

[jkbbwr]

Sorry for misunderstanding

[gildor]

@jkbbwr Actually Andrey Breslav and other people from Kotlin Team many times tell that they don’t want to have macroses, because of big problems with tooling. They want to provide compiler plugins API in the future, that allows to generate/modify some code and at the same time provide tooling for that (so compiler and IDE uses the same api of plugin)

Compiler plugins already available, but it’s private api that will be changed

[jkbbwr]

To be fair the desire for macros was more for a lack of untyped numerical support. Means to an end

[gildor]

Untyped numerical support? Can you show case, just curious

[gildor]

Oh, I see

[gildor]

you are talking about unsigned numbers

[jkbbwr]

Im writing a gameboy emulator in C at the moment, the gameboy treats everything as unsigned 8bit or unsigned 16, the math to work around the JVM lack of unsigned types sucks.

[gildor]

I think inline classes will help with it. They already have some early prototype of them

[jkbbwr]

Oh?!

[jkbbwr]

Interesting

[gildor]

Check this thread
https://kotlinlang.slack.com/archives/C0B9K7EP2/p1517228954000392

[gildor]

And this post
https://discuss.kotlinlang.org/t/when-does-bit-fiddling-come-to-kotlin/2249

implement unsigned numeric types as value types (represented as signed numbers under the hood)

And Inline classes is the feature that allows to do that

[jkbbwr]

Reading, for now Ill leave the code in C but the number of things I wont use kotlin for is shrinking by the day. I just hope that the language team don't go too far and actually stop before it ends up another C++14x

[gildor]

It's really essential feature that allows to implement unsigned numbers and improve type safety without runtime penalties. So I'm sure it's right direction.

[jkbbwr]

I wasn't commenting on that specific feature, I was more talking in general