# Language restriction to solve 15276?

**URL:** <https://discourse.julialang.org/t/language-restriction-to-solve-15276/10625>\
**Category:** Internals & Design\
**Created:** [April 30, 2018, 5:29pm UTC](https://discourse.julialang.org/t/language-restriction-to-solve-15276/10625 "2018-04-30T17:29:12Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![Stephen\_Vavasis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stephen_vavasis/32/3389_2.png) [@Stephen\_Vavasis](https://discourse.julialang.org/u/Stephen_Vavasis)\
**Post date:** [May 4, 2018, 1:23pm UTC](https://discourse.julialang.org/t/language-restriction-to-solve-15276/10625/18 "2018-05-04T13:23:29Z")

</div>

With respect to Jamii’s suggestion to catch occurrences of 15276 with static compile-time checking, what do you propose to do if a potential instance of 15276 is observed in the code? As I mentioned in an earlier post, the core developers have previously expressed opposition to compile-time warnings for legal code (see: [Cannot use size(::Array{Int, 2}): ERROR: LoadError: UndefRefError: access to undefined reference - #25 by Stephen\_Vavasis](https://discourse.julialang.org/t/cannot-use-size-array-int-2-error-loaderror-undefreferror-access-to-undefined-reference/4138/25)).

With regard to Jeff Bezanson’s explanation of why my proposed language restriction won’t solve the problem, how about the following. Introduce a new operator ::: which means that a variable occurring in an expression (presumably inside a closure) has a promised type, something like this:

```julia
    function t(s)
          a = s / 9
          x = Set((a:::typeof(s))^2 + a * i for i = 1 : 10)
          return x
    end

```

Would introduction of this operator make the problem go away?

---

_[View the full topic](https://discourse.julialang.org/t/language-restriction-to-solve-15276/10625)._