# Out intent error on \[\] real versus real confusion

**URL:** <https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006>\
**Category:** Users\
**Created:** [April 16, 2026, 6:41pm UTC](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006 "2026-04-16T18:41:51Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![nelsonluisdias](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/nelsonluisdias/32/691_2.png) [@nelsonluisdias](https://chapel.discourse.group/u/nelsonluisdias)\
**Post date:** [April 28, 2026, 9:18pm UTC](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006/5 "2026-04-28T21:18:36Z")

</div>

I have been thinking about this post that I initiated for some time. It is not the first time that I made a mistake regarding promotion; see [https://chapel.discourse.group/t/intent-in-real-but-compiler-accepts-a-whole-array/28211](https://chapel.discourse.group/t/intent-in-real-but-compiler-accepts-a-whole-array/28211)

It is of course the programmer's (myself) responsibility to know the language features and understand what happens when inserting an array in lieu of a scalar triggers promotion. On the other hand, because promotion is much less frequently needed than standard scalar arguments, I wonder if it would make sense to make promotion an explicit request (instead of an automatic decision by the compiler), as in

```chapel
proc haversine( const in x: || real) : || real { 
   return sin(x/2)**2 ;
}

```

Then the compiler would know that haversine is a candidate for promotion. Just a thought: neither a priority nor an actual feature request ...

Cheers

Nelson

---

_[View the full topic](https://chapel.discourse.group/t/out-intent-error-on-real-versus-real-confusion/49006)._
