Semantics of Listing typechecks have changed in 0.27 #245

New Issue

adam · 2025-12-30T01:22:39+01:00

adam commented

2025-12-30 01:22:39 +01:00

Originally created by @odenix on GitHub (Nov 5, 2024).

The following program fails in 0.26.3 but passes in 0.27.0.
(My understanding is that the goal was to preserve semantics of Listing typechecks.)

local a = new Listing { new Listing { 0 } }
// 0.26.3 fails here, 0.27.0 doesn't
local b = a as Listing<Listing<String>> 
local c = (b) { new Listing { 1 } }
local d = c as Listing<Listing<Int>>

result = d

Originally created by @odenix on GitHub (Nov 5, 2024). The following program fails in 0.26.3 but passes in 0.27.0. (My understanding is that the goal was to preserve semantics of Listing typechecks.) ``` local a = new Listing { new Listing { 0 } } // 0.26.3 fails here, 0.27.0 doesn't local b = a as Listing<Listing<String>> local c = (b) { new Listing { 1 } } local d = c as Listing<Listing<Int>> result = d ```

adam added the bug label 2025-12-30 01:22:39 +01:00

adam closed this issue

2025-12-30 01:22:39 +01:00

adam commented

2025-12-30 01:22:40 +01:00

@bioball commented on GitHub (Nov 5, 2024):

Ah, I think this is a regression in our typechecking logic. It shouldn't be possible to amend b and get members of type Listing<Int>.

@bioball commented on GitHub (Nov 5, 2024): Ah, I think this is a regression in our typechecking logic. It shouldn't be possible to amend `b` and get members of type `Listing<Int>`.

adam referenced this issue

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

[PR #245] [MERGED] Update to Gradle 8.6 #478

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#245