# Curious about needs for private record fields

**URL:** <https://discuss.ocaml.org/t/curious-about-needs-for-private-record-fields/2527>\
**Category:** Community\
**Created:** [September 6, 2018, 7:14pm UTC](https://discuss.ocaml.org/t/curious-about-needs-for-private-record-fields/2527 "2018-09-06T19:14:50Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![c-cube](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ocaml.org/c-cube/32/1727_2.png) [@c-cube](https://discuss.ocaml.org/u/c-cube)\
**Post date:** [September 6, 2018, 9:24pm UTC](https://discuss.ocaml.org/t/curious-about-needs-for-private-record-fields/2527/4 "2018-09-06T21:24:48Z")

</div>

If you want to expose some fields but not others, you can declare abstract types for the private fields. Inside the module this type is just an alias to the actual type, but outside, it makes the field totally unusable.

E.g

```ocaml
type generative_id (* can't do anything *)

type ast = {
   view: ast_view;
   ty : type_;
   id: generative_id; (* effectively private *)
}
and ast_view = Add of ast * ast | …
and type_ = …

```

edit: an additional benefit is that you can pattern-match on such records.

---

_[View the full topic](https://discuss.ocaml.org/t/curious-about-needs-for-private-record-fields/2527)._