# Pipe operator in extensible record type
**URL:** https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012
**Category:** Learn
**Created:** [February 27, 2021, 8:38am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012 "2021-02-27T08:38:03Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@JohnQWang](https://discourse.elm-lang.org/u/JohnQWang)
#### Post date: [February 27, 2021, 8:38am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/1 "2021-02-27T08:38:03Z")
I came across extensible record code like the following:
```auto
type alias Editable r
= { r | author: String, created : Int }
```
I understand it’s saying _"I’m creating a `record` type who can hold any fields so long as it has two particular fields `author` and `created`"_. However I have not seen the pipe operator being introduced in creating record `type` in the office document. It’s indeed explained as a way to update a record `value` though.
Is it some sort of hack or it has a general usage beyond the definition of extensible record?
---
### Author:  [@DullBananas](https://discourse.elm-lang.org/u/DullBananas)
#### Post date: [February 27, 2021, 8:48pm UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/2 "2021-02-27T20:48:25Z")
i don’t understand your question
---
### Author:  [@georgesboris](https://discourse.elm-lang.org/u/georgesboris)
#### Post date: [February 27, 2021, 9:16pm UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/3 "2021-02-27T21:16:03Z")
Your understandment is correct - the | symbol is present on two different situations, meaning two different things. When defining a type alias it is used to represent an extensible record. But it can also mean “return this record with this update”. Those two usages are unrelated.
---
### Author:  [@opvasger](https://discourse.elm-lang.org/u/opvasger)
#### Post date: [February 27, 2021, 11:04pm UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/4 "2021-02-27T23:04:52Z")
extensible records, like the one you’ve shown, exists as a tool for “narrowing” types - this video should start at 21:29, where it’s described 🙂
I’d recommend watching the whole video though!
[ ](https://www.youtube.com/watch?v=DoA4Txr4GUs)
---
### Author:  [@JohnQWang](https://discourse.elm-lang.org/u/JohnQWang)
#### Post date: [February 28, 2021, 12:48am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/5 "2021-02-28T00:48:01Z")
Yes, I’ve already watched it and planed to watch it again. It’s awsome.
---
### Author:  [@JohnQWang](https://discourse.elm-lang.org/u/JohnQWang)
#### Post date: [February 28, 2021, 1:27am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/6 "2021-02-28T01:27:44Z")
Sorry for my bad English expression. I mean how can a pipe operator be used in defining a record type? According to these well-known documents(e.g., [offical guide](https://guide.elm-lang.org/architecture/), [Beginning Elm](https://elmprogramming.com/)), a pipe is used to updating a `record value`, not to compose a new `record type`.
So I’m wondering If I’ve missed some key concepts of Elm.
---
### Author:  [@DullBananas](https://discourse.elm-lang.org/u/DullBananas)
#### Post date: [February 28, 2021, 1:38am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/7 "2021-02-28T01:38:42Z")
The syntax for extensible records and record update expressions have a similar meaning, but they do something different. It’s similar to how arguments exist for both types and functions.
---
### Author:  [@dta](https://discourse.elm-lang.org/u/dta)
#### Post date: [March 1, 2021, 11:47pm UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/8 "2021-03-01T23:47:21Z")
I’m surprised that the official language guide does not mention extensible record types. I’m sure that must have been where I first read about them years ago, but I don’t see any mention of them now.
It actually looks like it used to be on [this page](https://elm-lang.org/docs/records), but was [removed](https://github.com/elm/elm-lang.org/commit/6b0e34930a02c527d2545bc9b34908815920a9e8).
---
### Author:  [@JohnQWang](https://discourse.elm-lang.org/u/JohnQWang)
#### Post date: [March 2, 2021, 1:24am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/9 "2021-03-02T01:24:31Z")
Really? It appeared and dispeared again? What happened? The `extensible record` seems an important concept when building large application. The Richard’s video has shown the importance in narrowing type. I love this concept.
---
### Author:  [@francescortiz](https://discourse.elm-lang.org/u/francescortiz)
#### Post date: [March 2, 2021, 7:16am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/10 "2021-03-02T07:16:20Z")
Following Evan recommendation, I wouldn’t use them. The compiler has bugs dealing with them and it is recommended using record composition over extensible records. Also consider how you would reuse/compose decoders. For example:
```elm
type alias PersonalDetails a =
{ a
| name : String
, age : Int
}
type alias AccessData a =
{ a
| isAdmin : Bool
, isBanned : Bool
}
type Profile =
PersonalDetails (AccessData {})
```
VS
```elm
type alias PersonalDetails =
{ name : String
, age : Int
}
type alias AccessData =
{ isAdmin : Bool
, isBanned : Bool
}
type Profile =
{ details : PersonalDetails
, access : AccessData
}
```
PS: I would be surprised that they are removed in future releases of Elm.
---
### Author:  [@opvasger](https://discourse.elm-lang.org/u/opvasger)
#### Post date: [March 2, 2021, 7:45am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/11 "2021-03-02T07:45:40Z")
What you’re discussing is data-modeling, which is what they’re discouraged for.
Using extensible-records is definitely not discouraged, and I’m very confident they’re not going anywhere.
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [March 2, 2021, 8:50am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/12 "2021-03-02T08:50:06Z")
Nothing wrong with using them in data modelling either - just don’t expect them to work like subtypes in the same way that extending objects in OO works.
---
### Author:  [@opvasger](https://discourse.elm-lang.org/u/opvasger)
#### Post date: [March 3, 2021, 3:58pm UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/13 "2021-03-03T15:58:25Z")
> [@rupert](#):
>
> Nothing wrong with using them in data modelling either
“Extensible records are useful for restricting arguments, not data-modeling” - evancz, the video above.
I’m fairly certain this still holds true
---
### Author:  [@rupert](https://discourse.elm-lang.org/u/rupert)
#### Post date: [March 3, 2021, 4:28pm UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/14 "2021-03-03T16:28:04Z")
Just because someone says (or writes) something does not make it true. You need some kind of logic to make a case. I would not use them in data modelling carelessly, but I think occasionally they can work nicely there. Mostly if you have some kind of linear pipeline process that builds up fields as processing works down the pipeline - it can be nice to model each stage as an extensible group of fields, with the final output made up of all the parts. The alternative of modelling each stage separately is that you might add a field to one stage but forget to add it to all the others further down the pipeline.
I used them once to define an extensible API with common base functions and multiple implementations - that was quite OO, but worked for the use case.
I think the advice should be “Extensible records are most useful for restricting arguments, not data-modeling”.
---
### Author:  [@opvasger](https://discourse.elm-lang.org/u/opvasger)
#### Post date: [March 3, 2021, 5:41pm UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/15 "2021-03-03T17:41:07Z")
> [@rupert](#):
>
> Just because someone says (or writes) something does not make it true.
😕
I’m mean to pass on what I consider solid advice, as it has made things easier for me in the past. I don’t want to argue it’s merits in this thread ☀
EDIT: But I suppose it could be interesting to start a new thread to discuss the subject!
---
### Author:  [@JohnQWang](https://discourse.elm-lang.org/u/JohnQWang)
#### Post date: [March 4, 2021, 3:37am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/16 "2021-03-04T03:37:12Z")
As newbie of elm, I like to read the new thread if it’s created 😉 .
To me, “restricting arguments” is highly related to “data-modeling”. It seems an elm application is pretty much just a big(flat) data(model) surrounded by a lot of logic(functions). So “restricting arguments” is an important way to deal with that data. By what I’ve learned about elm so far(which is limited BTW), it’s one of the key concepts one must grasp to build serious application.
---
### Author:  [@opvasger](https://discourse.elm-lang.org/u/opvasger)
#### Post date: [March 4, 2021, 11:15am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/17 "2021-03-04T11:15:32Z")
For myself, the distinction is whether we’re talking types of function-arguments, or types of application state.
I haven’t had any practical uses for extensible-records on types that live inside the “Model” ☀
---
### Author:  [@system](https://discourse.elm-lang.org/u/system)
#### Post date: [March 14, 2021, 11:16am UTC](https://discourse.elm-lang.org/t/pipe-operator-in-extensible-record-type/7012/18 "2021-03-14T11:16:27Z")
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.