I’m creating a type alias to a type record, but it’s not compiling (see attached non-compiling ellie). What I’m trying to do is take a Person from Model and ignore all fields other than name, while the compiler is telling me the name field doesn’t exist, as if it’s losing the name field somehow… --…

Others have noticed in the past that type aliases to extensible records don’t seem to be fully supported: [image] Using extensible records in type aliases Learn I have a project with a lot of very similar but slightly different data types, so I’ve been making a lot of use …

Elm implementation of extensible records seems inconsistent and there is no public statement of whether it is a bug or it is intentional. Check this intellij-elm issue where this was discussed before: intellij type checker reports error in valid code …

With ExtensibleData c you idenity c as the type without the field name. So the subInit function return a type SubModel c which resolved to SubModel {age :Int}. This is not compatible with your Model where you expect SubModel { name : string, age: Int}

With ExtensibleData c you idenity c as the type without the field name . So the subInit function return a type SubModel c which resolved to SubModel {age :Int} . This is not compatible with your Model where you expect SubModel { name : string, age: Int} I thought type alias ExtensibleData c = { c…

[image] TankorSmash: I thought type alias ExtensibleData c = { c | name : String } means anything can be c , so long as it’s got name : String in it, but you’re saying this is c plus name : String . That matches my understanding as well. I generally use extensible records as “this function ta…

I think what’s happening is mixing up the use of extensible records in a function definition and the use of extensible records in aliases. The function getName : { r | name : String } -> String getName { name } = name is an example of using extensible records to say “This function expects a recor…

The problem comes indeed from this type annotation subInit : ExtensibleData c -> SubModel c Both c’s in ExtensibleData c -> SubModel c need to be exactly the same type. That’s how generic types work. Because { c | name : String } means that the c type doesn’t necessarily already have a name proper…

Extensible Records seems to be pruning fields and failing to compile

Learn

Topic		Replies	Views
Using extensible records in type aliases Learn	1	844	April 11, 2020
Understanding extensible records Learn	5	3042	November 21, 2019
Compiler trips up on extensible records? Learn	25	2407	May 11, 2020
Change records to be extensible by default in Elm Request Feedback	12	1538	July 28, 2020
Pipe operator in extensible record type Learn	16	1210	March 4, 2021

Extensible Records seems to be pruning fields and failing to compile

Related topics