# MATLABArrays.jl needed (similar to ElasticArrays.jl)

**URL:** <https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108>\
**Category:** General Usage\
**Created:** [September 5, 2020, 3:18pm UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108 "2020-09-05T15:18:28Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [September 5, 2020, 8:41pm UTC](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108/5 "2020-09-05T20:41:22Z")

</div>

I agree, for all new code–written from scratch–I would rather have Julia’s default behavior. I’m only thinking of a new type to help with porting, kind of like training wheels, you could later take off (or not), why I want the exact same semantics, then could later change to “`1 + only([1])`”. The first step would be such a type, and possibly a package, with a macro to apply it (to e.g. functions) with same syntax, similar to e.g.:

> **[GitHub - JuliaMath/ChangePrecision.jl: macro to change the default...](https://github.com/JuliaMath/ChangePrecision.jl)**
>
> macro to change the default floating-point precision in Julia code - GitHub - JuliaMath/ChangePrecision.jl: macro to change the default floating-point precision in Julia code

If you want MATLAB-semantics globally, this could help (extended to arrays):

> [@\[ANN\] SafeREPL: use BigInt by default at the REPL](https://discourse.julialang.org/t/ann-saferepl-use-bigint-by-default-at-the-repl/41271):
>
> With Julia 1.5 around the corner, I’m happy to present [SafeREPL](https://github.com/rfourquet/SafeREPL.jl), a little experimental package which by default interprets Int and Int128 REPL literals as BigInt, and Float64 literals as BigFloat: julia\> using SafeREPL julia\> factorial(40) 815915283247897734345611269596115894272000000000 julia\> sqrt(2.0) 1.414213562373095048801688724209698078569671875376948073176679737990732478462102 julia\> c = 299\_792\_458; c^3 # the cube of the speed of light can even be computed safely! 26944002417373989…

As always in software, you should first get correct, then optimize for speed. So, you would take off the “training-wheels” to enable the faster Julia semantics (assuming the semantics of growing arrays automatically isn’t actually used). Or for non-speed critical code could leave in.

---

_[View the full topic](https://discourse.julialang.org/t/matlabarrays-jl-needed-similar-to-elasticarrays-jl/46108)._