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 the
in.
>
> On Thu, Aug 3, 2017 at 7:00 AM, Stephen Canon via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Aug 2, 2017, at 6:37 PM, Nicolas Fezans via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I am of course not talk
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) shou
On Thu, Aug 3, 2017 at 12:42 AM, Xiaodi Wu wrote:
>
> On Wed, Aug 2, 2017 at 17:37 Nicolas Fezans
> wrote:
>
>> 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
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,
graphs
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
> > would be a mu
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 increase
+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 T
> 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
> 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, n
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 le
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 multiplicatio
+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 compile-t
> 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
> 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.
https://de
> 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 sligh
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
.org> wrote:
>>
>> I really have nothing to add to this discussion, except for this fun
>> fact: apparently, the backslash was added to ASCII so you could write /\
>> and \/ operators: http://www.bobbemer.com/BACSLASH.HTM
>>
>> Slava
>>
>> On Feb 5,
at 4:55 PM, Derrick Ho 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> wrote:
>
>> Dear all,
>
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 leas
+1
On Tue, Jan 31, 2017 at 11:55 AM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:
> One of the biggest issues that I saw while teaching Swift to newbies (most
> had not programmed before) is confusion based on the early warnings/errors
> that swift/xcode gives you as they typ
f */
> >return
> > }
> >
> > /* stuff with names */
> > }
> >
> > l8r
> > Sean
> >
> >
> >
> >> On Feb 1, 2017, at 12:18 PM, Nicolas Fezans via swift-evolution <
> swift-evolution@swift.org> wrote:
> >&g
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, Saagar
23 matches
Mail list logo