Typo generates Scala 3 syntax

[nafg]

Doesn't compile on Scala 2.

I have this in the generated code:

implicit lazy val StringArrayEncoder: zio.jdbc.JdbcEncoder[Array[java.lang.String]] = zio.jdbc.JdbcEncoder.singleParamEncoder(using StringArraySetter)

(note the using)

[nafg]

I solved that by rolling back to 0.7.1. But now I have another issue. It generates calls to .selectStream without parentheses but it needs parentheses even though the parameter has a default value (at least on Scala 2, don't know about Scala 3).

[nafg]

If Typo is meant to be used as just a library, why am I passing in a finite DbLibName, why can't I just extend some interface and pass that into Typo? In particular I should be able to override and customize an existing one.

[oyvindberg]

Sorry, I'll document it better. For Scala 2 with the latest release you'll need options: -Xsource:3 to compile the code. The shared subset is getting smaller and smaller by the release unfortunately.

For zio-jdbc those parenthesis are necessary with the newest version. Bump it and it should work.

[oyvindberg]

As for closed set, I figured it was best to start out this way. There are no guarantees for stability for the stuff in internal package, while the public interface should be stable(-ish, pending a 1.0 release) .

Nothing stops you from copy/pasting the code you're calling and customize the codegen, but I might heavily refactor that code

[nafg]

Sorry, I'll document it better. For Scala 2 with the latest release you'll need options: -Xsource:3 to compile the code. The shared subset is getting smaller and smaller by the release unfortunately.

I use -Xsource:3. I don't think that makes using valid.

For zio-jdbc those parenthesis are necessary with the newest version. Bump it and it should work.

The problem was it omitting them. But if 0.8.0 doesn't have that issue then it's just the first issue.

Anyway I had to take a different approach meanwhile for now.

[nafg]

As for closed set, I figured it was best to start out this way. There are no guarantees for stability for the stuff in internal package, while the public interface should be stable(-ish, pending a 1.0 release) .

Nothing stops you from copy/pasting the code you're calling and customize the codegen, but I might heavily refactor that code

I would have to copy-paste a lot of the codebase, from what I can tell

[oyvindberg]

It does compile in this repo, including for 2.12 with using. Is it something else which affects it?

[oyvindberg]

I would have to copy-paste a lot of the codebase, from what I can tell

I suppose you can fork it, or suggest improvements - maybe you want something which is generally useful.

As part of the effort to port the generated code to Java, there will be much greater opportunities to customize the generated code in a structured manner. But there is a ton of work missing before I can ship it