<div dir="ltr">Your notation is indeed correct, even though using x on both side might confuse some people, this is correct. But no I would not go that far, but I think the example I just replied before which should execute also on octave/scilab (most people in the list probably do not have a matlab license) should show how compact this syntax is.<div>I often need to rewrite in C or C++ algorithms that were developed and validated first on Matlab and it occurs very frequently that the lack of appropriated syntax (even when using libraries with a lot of functions) makes the code extremely longer and very much less readable for me. Of course, each line of C/C++ is simple to understand because in such cases they do not do much things, but you rapidly get several levels of embedded loops to do what was written in one or two lines of Matlab code, and in the end you often do not see the main idea anymore or it is much harder to see it. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 1:17 AM, David Sweeris <span dir="ltr">&lt;<a href="mailto:davesweeris@mac.com" target="_blank">davesweeris@mac.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br></div><div><div><br><br>Sent from my iPad</div><span class="">On Aug 2, 2017, at 3:43 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></span></div><span class=""><blockquote type="cite"><br><div class="gmail_quote"><div dir="auto">On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans &lt;<a href="mailto:nicolas.fezans@gmail.com" target="_blank">nicolas.fezans@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>I think that the items mentioned earlier in the list (just reminded below) should not all be treated equally.<br></div><div><br></div><div><div style="font-size:12.800000190734863px"><div><div><div></div></div></div></div></div></div><div><div><div style="font-size:12.800000190734863px"><div><div><div><div>- RNG and cryptography library (CryptoSwift could be a good base for this)<br></div>- Generic Math library/Vector library<br></div></div></div></div></div></div><div><div><div style="font-size:12.800000190734863px"><div><div>- Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList, graphs, etc)<br></div></div></div></div></div><div><div><div style="font-size:12.800000190734863px"><div><div></div>- Modern DateTime library<br></div></div></div></div><div><div><div style="font-size:12.800000190734863px"><div>- Modern String processing toolkit<br></div>- 2D Graphics library (similar to cairo)<br></div></div></div><div><div><div style="font-size:12.800000190734863px"></div><span style="font-size:12.800000190734863px">- Windowing/UI library</span><br></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">By that I mean that I see at least one distinction to make between:</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">a) the libraries that would make Swift and the programmer experience with these libraries under Swift significantly better if they are (or at least feel) deeply integrated in the language (for instance with associated </span><span style="font-size:12.800000190734863px">syntax / </span><span style="font-size:12.800000190734863px">syntax sugar)</span></div><div><span style="font-size:12.800000190734863px">    and </span></div><div><span style="font-size:12.800000190734863px">b) those that would not really benefit from such an integration to the language.</span></div><div><span style="font-size:12.800000190734863px"><br></span></div><div><span style="font-size:12.800000190734863px">For me a core math library, clearly belongs to category a)</span></div><div><span style="font-size:12.800000190734863px">I am of course not talking about a syntax sugar to call a sin or cos function, but rather to manipulate other objects such as N-dimensional matrices, defining maths functions that can take such matrices as argument e.g. sin(A) with A as matrix produces a matrix of the same size where all elements are the sinus values of the elements of A (sorry but things like this calling map() with &#39;sin&#39; looks quite ugly for scientists).</span></div><div><span style="font-size:12.800000190734863px">Such a good math syntax should be compact enough to have complete equations looking &quot;close enough&quot; to the maths equations you could have written in a LaTeX or Word documentation of your scientific code. IMO a well integrated swift core math library should feel a Julia or Matlab code (while still having the power of Swift in terms of speed and modern programming paradigms) instead of looking and feeling like &#39;numpy&#39;. But the latter is what you get if you just make a math library with no integration to the language syntax, operators, and basic functions.</span></div><div><span style="font-size:12.800000190734863px"></span></div></div></blockquote><div dir="auto"><br></div><div dir="auto">I agree that if this would require compiler support, then it needs to be part of the standard library. However, I don&#39;t see anything about what you describe that cannot be supported as a third-party library.</div></div></blockquote><br></span><div>Getting the syntax right could possibly require some compiler changes. Maybe. Depends on what &quot;right&quot; means. Declaring a variable, x, to be &quot;the set of all real numbers such that x*sin(x) is an integer&quot; using syntax like this, &quot;let x = {x <span style="background-color:rgba(255,255,255,0)">∈ ℝ | x * sin(x) ∈ ℕ}&quot;, would be neat (I&#39;m a bit hazy on my set notation... that might not actually be correct).</span></div><div><span style="background-color:rgba(255,255,255,0)">We&#39;re actually not that far off from that, compiler-wise, I mean. Aside defining the relevant types, operators, and identifiers, that exact syntax pretty much just requires the compiler to allow using a certain types of variables in their own declaration and either one heck of an `ExpressibleByClosureLiteral` protocol, or improvements to the type inference engine.</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">- Dave Sweeris</span></div></div></blockquote></div><br></div>