Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

Interesting figures. I will not try to discuss the generics, inlineable, etc. there are certainly good observations and comments to make here, but most people in this list know certainly more about it than I do. I just want to point out that IMO a core math library for swift should comply with

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

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)

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

I think that the items mentioned earlier in the list (just reminded below) should not all be treated equally. - RNG and cryptography library (CryptoSwift could be a good base for this) - Generic Math library/Vector library - Basic data structures (Tree, Balanced Tree, Heap, Queue, SkipList,

Re: [swift-evolution] Yet another fixed-size array spitball session

On Mon 29. May 2017 at 20:57, David Sweeris via swift-evolution < swift-evolution@swift.org> wrote: > > > On May 29, 2017, at 01:12, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I agree strongly that the syntax looks awkward — imho > > var v: Vector >

Re: [swift-evolution] [Pitch] New collection-based 'repeat' API

On Tue, May 2, 2017 at 8:50 AM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > I'm not giving my opinion, but quoting Ben Cohen's great list of questions > to ask ourselves before adding something to the Standard Library: > > All methods added to the standard library

Re: [swift-evolution] 'T != Type' in where clause

+1 I would also welcome to be able to use "or" and "and" logical operators (not only the not operator) on these constraints. I have sometimes generic functions whose code is identical but is written twice: first with 'where T=P1' and then with 'where T=P2', being able to write for instance 'where

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> Once such a library were reasonably mature, it would be reasonable to propose it for inclusion in swift proper. I expect this process will take a couple *years*. Yes, I do not expect this to come very quickly either but if no one gets started, that is going to last for even longer ;-) > or the

Re: [swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

> If you're simply looking for elementwise multiply without performance > requirements, map(*) is a very succinct spelling. Yes, it is (combined with zip), but: 1) zip map will not enforce same size (which shall be done to fail hard early), nor allow to combine with an array of a single element,

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

I do not see the rationale behind marking impure functions explicitly. The useful property is to be pure, in case a function is impure or it's status is unknown you just have to assume the worse, i.e. that it is impure. The arrow proposals -> vs. ~> vs. => are not really much shorter than the 4

[swift-evolution] Basic element-wise operator set for Arrays, Arrays of Arrays, etc.

Dear all, In swift (just as in many other languages) I have been terribly missing the operators like .* ./ .^ as I know them from MATLAB/Scilab. These operators are very handy and do element-wise operations on vectors or matrices of the same size. So for instance A*B is a matrix

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

+1 for pure functions +1 for combining them with constexpr -1 for the syntax originally proposed +1 for pure or @pure keywords (before func and before a closure opening { ) One thing is probably worth considering if pure functions and closures are combined with constexpr and evaluated at

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> Not only that, but even if you pass a value type as a parameter, that value type might have reference types as ivars. I think that arguments passed to a pure function shall be checked against containing such references or objects that contains such references themselves: I guess that this check

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> If it mutates whatever the input is referencing, it would have a side-effect which makes it "not pure" (for my understanding of what “pure” means). I am not really sure of it (I have not played around with it until now) but I don't think that this is an issue with the swift inout, cf.

Re: [swift-evolution] Proposal to change Logical NOT Operator from exclamation mark ( ! ) to something else

> 3: maybe ~ is a better fit? just for information this is in line with Matlab in which the following three "not"-related syntax exist: a) ~ as a prefix operator for not b) not as a function c) ~= as an infix operator for "is not equal to" I see pros and cons for each option and have a very

Re: [swift-evolution] Allow ' in variable/constant names?

So yeah, solution is to make characters easier to type, not modify the language. +1 to that: what about having editors which provide a graphical access to such characters just as LaTeX editors give access to maths symbols and some functions? The equation editors of other softwares (e.g. recent MS

Re: [swift-evolution] define backslash '\' as a operator-head in the swift grammar

4:55 PM, Derrick Ho <wh1pch...@gmail.com> wrote: > If the \ operator is not defined in swift, does it treat it as something > that can be operator overloaded? > > > On Sun, Feb 5, 2017 at 10:29 AM Nicolas Fezans via swift-evolution < > swift-evolution@swift.org&g

[swift-evolution] define backslash '\' as a operator-head in the swift grammar

Dear all, This is a rather simple proposal to add '\' (backslash character) as a valid operator-head in the swift grammar. One argument for it, is that there exist a backslash operator in the MATLAB/Scilab/Octave languages. In this languages A\B solves the linear system A*X = B for X (or the

Re: [swift-evolution] for-else syntax

> >/* stuff */ > >return > > } > > > > /* stuff with names */ > > } > > > > l8r > > Sean > > > > > > > >> On Feb 1, 2017, at 12:18 PM, Nicolas Fezans via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] for-else syntax

I tend to write this kind of treatment the other way around... if names.isEmpty { // do whatever } // on other cases I might have a few else-if to treat other cases that need special treament else { for name in names { // do your thing } } Nicolas Fezans On Wed, Feb 1, 2017 at 6:31 PM,