Type parameters in new Mapping<TypeA, TypeB>/ new Listing<Type> are not checked #136

New Issue

adam · 2025-12-30T01:21:24+01:00

adam commented

2025-12-30 01:21:24 +01:00

Originally created by @bioball on GitHub (Apr 6, 2024).

This does not throw, but should:

foo = new Listing<Int> {
  "hello"
}

In the below, both types should be checked:

foo: Listing<Int(isEven)> = new Listing<Int(this > 5)> { 1; 2; 3 }

The check should not follow when amended.

This is fine:

foo: new Listing<Int> { 1; 2; 3 }

bar = (foo) { "hello" }

This should probably be fine too:

foo = new Listing<Int> { 1 } { "hello" }

Originally created by @bioball on GitHub (Apr 6, 2024). This does not throw, but should: ``` foo = new Listing<Int> { "hello" } ``` In the below, both types should be checked: ``` foo: Listing<Int(isEven)> = new Listing<Int(this > 5)> { 1; 2; 3 } ``` The check should not follow when amended. This is fine: ``` foo: new Listing<Int> { 1; 2; 3 } bar = (foo) { "hello" } ``` This should probably be fine too: ``` foo = new Listing<Int> { 1 } { "hello" } ```

adam added the bug label 2025-12-30 01:21:24 +01:00

adam closed this issue

2025-12-30 01:21:24 +01:00

adam commented

2025-12-30 01:21:24 +01:00

@odenix commented on GitHub (Apr 12, 2024):

A pragmatic solution would be to allow x: Listing<A> = new Listing {...} but not x = new Listing<A> {...}. This would reflect the (current) reality that generics aren't reified. It would also encourage users to do the right thing and put type annotations on their properties. It might even allow to phase out new Type {...} in favor of (Type) {...}, which in my view is a nicer literal syntax.

@odenix commented on GitHub (Apr 12, 2024): A pragmatic solution would be to allow `x: Listing<A> = new Listing {...}` but not `x = new Listing<A> {...}`. This would reflect the (current) reality that generics aren't reified. It would also encourage users to do the right thing and put type annotations on their properties. It might even allow to phase out `new Type {...}` in favor of `(Type) {...}`, which in my view is a nicer literal syntax.

adam commented

2025-12-30 01:21:25 +01:00

@holzensp commented on GitHub (Apr 16, 2024):

That's less simple than you might think. The generic informs the default / IDE type checking. It's a common pattern to define Listings inline to produce something of a very different type, such as new Listing<String> { ... }.join(", ") to produce a String.

@holzensp commented on GitHub (Apr 16, 2024): That's less simple than you might think. The generic informs the default / IDE type checking. It's a common pattern to define `Listing`s inline to produce something of a very different type, such as `new Listing<String> { ... }.join(", ")` to produce a `String`.

adam commented

2025-12-30 01:21:25 +01:00

@odenix commented on GitHub (Apr 17, 2024):

Dealing with generics is never simple. Regarding your concrete arguments, Listing.join is defined for all Listings, not just Listing<String>. And IDEs could still try to infer the element type from the given elements. The default sounds like a bigger problem, but maybe there is an acceptable solution.

@odenix commented on GitHub (Apr 17, 2024): Dealing with generics is never simple. Regarding your concrete arguments, `Listing.join` is defined for all `Listing`s, not just `Listing<String>`. And IDEs could still try to infer the element type from the given elements. The default sounds like a bigger problem, but maybe there is an acceptable solution.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#136

Type parameters in new Mapping<TypeA, TypeB>/ new Listing<Type> are not checked #136

Type parameters in `new Mapping<TypeA, TypeB>`/ `new Listing<Type>` are not checked #136