# Should we avoid assignment of derived types in robust programs?

**URL:** <https://fortran-lang.discourse.group/t/should-we-avoid-assignment-of-derived-types-in-robust-programs/2359>\
**Category:** Uncategorized\
**Created:** [December 2, 2021, 8:59am UTC](https://fortran-lang.discourse.group/t/should-we-avoid-assignment-of-derived-types-in-robust-programs/2359 "2021-12-02T08:59:37Z")\
**Posts on this page:** 1\
**Showing post:** 35

<div class="post-metadata">

**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\
**Post date:** [January 22, 2022, 5:12am UTC](https://fortran-lang.discourse.group/t/should-we-avoid-assignment-of-derived-types-in-robust-programs/2359/35 "2022-01-22T05:12:07Z")

</div>

> [@aradi](#):
>
> . @sblionel Can you show me a way to resolve this conflict (without using an embedding type as discussed above)? Is it possible at all according to the current standard? …

So the “lesson” to be learned here (as per my hints in earlier posts across a couple of threads on this topic) is

- **Avoid** implementing defined assignment in a “container” derived type, rely instead on intrinsic assignment semantics as provided in the standard, and
- Should the “container” derived type need to have “components” for which the intrinsic assignment might be seen as inadequate e.g., those with `POINTER` attribute, then **wrap** such components themselves in a derived type that has a suitably defined assignment.

---

_[View the full topic](https://fortran-lang.discourse.group/t/should-we-avoid-assignment-of-derived-types-in-robust-programs/2359)._
