Howdy,
Matt Godbolt and I have added Swift support to his compiler explorer project
https://swift.godbolt.org/
It let's you interactively explore assembly emitted by the Swift compiler.
Right now, if you want the compiler to emit Intel syntax instructions, pass
"-emit-assembly -Xllvm --x86-asm-s
The midi conversation went south the second it started.
> Heh, you're missing my point
No you are missing mine. It doesn't make sense for two days to combine. It
totally makes sense for two signals to combine.
> If you want to treat your midi notes as bare numbers that can be added
and have no s
> here weren't one, that hypothetical machine is, logically speaking,
stripping the absolute-pitch-ness off of the MIDI note used for
transposition and using it as a relative pitch offset.
Indeed.
> It's like the relationship between dates on the calendar and time
intervals (10 days).
No it's no
:13 PM, Tony Allevato
wrote:
>
>
> On Mon, Dec 26, 2016 at 1:59 PM Adam Nemecek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > Huh? You just said that one usage scenario was the allocation of
>> buffers of known size. If you're unsatisfie
ripling the frequency gets you an octave + a perfect fifth. If you work
>> through the mathematics behind this, you'll understand the issues behind
>> equal temperament and well temperament.
>>
>> You are not multiplying pitch by pitch but pitch by number. Pitch + Pitch
> T() as a placeholder is just as valid/invalid as any other value in T's
space.
Correct but you how do you get any other value?
On Mon, Dec 26, 2016 at 1:39 PM, Tony Allevato via swift-evolution <
swift-evolution@swift.org> wrote:
>
>
> On Mon, Dec 26, 2016 at 1:19 PM David Sweeris wrote:
>
s a context, or the context is a factory that returns instances.) By
>> writing an algorithm that relies on DefaultConstructible, you prohibit
>> those types from being used there. If the algorithm pushes the
>> responsibility to the caller, as Array(repeating:count:) does, then i
intervals and you realize that the computational distinction
between the two is tenuous at best. But this discussion is neither here,
nor there.
On Mon, Dec 26, 2016 at 1:09 PM, Xiaodi Wu wrote:
> On Mon, Dec 26, 2016 at 1:50 PM, Adam Nemecek via swift-evolution <
> swift-evolution@swift.o
; DefaultConstructible version.
>
> The reason NSObject has a default initializer is because every object
> inherits from it and it must have a sensible default initializer to end the
> call chain, and there's nothing meaningful that needs to be parameterized
> for NSObject. If
> Array already has init(repeating:count:) that puts the responsibility of
choosing the default value at the call site. If someone were writing a
generic algorithm around this, then why not just propagate that
responsibility out to its call site as well? That way, the algorithm isn't
making any ass
enient for a
particular use case.
Because the identity associated with the default initializer as is is the
additive identity which means the default operation is addition.
On Mon, Dec 26, 2016 at 11:57 AM, Tony Allevato
wrote:
> On Mon, Dec 26, 2016 at 11:43 AM Adam Nemecek via swift-evolution
t all", personally.
> On Mon, Dec 26, 2016 at 11:27 AM Adam Nemecek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> The elements already have an Identity, the one that you get when you
>> invoke the default constructor. It's 0 for Int, ""
The elements already have an Identity, the one that you get when you invoke
the default constructor. It's 0 for Int, "" for String.
On Mon, Dec 26, 2016 at 11:24 AM, David Sweeris wrote:
>
> On Dec 26, 2016, at 11:12, Tino Heth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> There
s.xyz>>
> >>> wrote:
> >>> Well, reflection is a huge performance drop. Protocol conformance is
> way better.
> >>>
> >>> I'm not sure how huge it would be in the grand scheme of things; in
> >>> your example, you
orythmical stuff that requires Zero.
> >>
> >>
> >> I'm still not convinced there exist credible use cases that need to be
> >> generic over both collections and floating point, for instance. In
> fact, in
> >> my experience, there are few mat
erent
>>>> algebras isn't mutually exclusive with writing generic algorithms that rely
>>>> on this protocol, you can always introduce some monoidic wrapper type that
>>>> defines the more appropriate default value and operation.
>>>>
>>&g
ivalent to having `reduce` use the additive identity as the
> default initial result when + is the accumulator function and the
> multiplicative identity when * is the accumulator function (with the
> accumulator function being invoked starting with the element at array index
> 0). It does n
hat practical use cases are
>> there for an explicit DefaultConstructible that are impractical today?
>>
>>
>> On Sun, Dec 25, 2016 at 11:37 AM, Xiaodi Wu wrote:
>>>
>>>> Can you give some other examples of generic algorithms that would make
>&g
c over all
> DefaultConstructible types. My question is: what practical use cases are
> there for an explicit DefaultConstructible that are impractical today?
>
>
> On Sun, Dec 25, 2016 at 11:37 AM, Xiaodi Wu wrote:
>>
>>> Can you give some other examples of generic algor
t; of this DefaultConstructible? I'm having trouble coming up with any other
> than reduce.
> On Sun, Dec 25, 2016 at 14:23 Adam Nemecek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> This protocol is present in C++ http://en.cppreference.com/w/cpp/con
This protocol is present in C++
http://en.cppreference.com/w/cpp/concept/DefaultConstructible as well as in
Rust https://doc.rust-lang.org/std/default/
It's the identity element/unit of a monoid or a zero.
The Swift implementation is very simple (I'm open to different names)
protocol DefaultCons
https://lists.swift.org/pipermail/swift-evolution/2015-December/32.html
On Wed, Jun 8, 2016 at 2:30 PM, Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:
> I think keeping operators as actual operators is preferable. Having *some* but
> not all operators be keywords makes the
to every other programming
language that looks like it.
I'm not crazy about the `%%` spelling, but I can't think of anything better
either at the moment.
On Mon, May 23, 2016 at 12:24 PM Adam Nemecek via swift-evolution
wrote:
That kind of breaks backwards compatibility.
Also current
That kind of breaks backwards compatibility.
Also currently in swift, the % operator is called the remainder operator,
not the modulo operator, so technically the current implementation is
correct. In Haskell for example, there are two functions, rem (as in
remainder) and mod (as in modulo). I gue
.
> Truncating and flooring division are the most common by a wide margin,
> however.
>
> On May 21, 2016, at 4:22 PM, Adam Nemecek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hello,
>
> I think that Swift could use the 'double modulo' o
>>
>> To the same end result surely? Unless I’m missing something it seems
>> redundant.
>>
>> If there is a use-case for this, would it make more sense to have the
>> return type as an enum with cases for Positive, Negative and Zero?
>>
>> On 22 May 20
ng it seems
> redundant.
>
> If there is a use-case for this, would it make more sense to have the
> return type as an enum with cases for Positive, Negative and Zero?
>
> On 22 May 2016, at 08:07, Adam Nemecek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
Lol, I'll search harder next time. :-)
On Sun, May 22, 2016 at 11:30 AM, Erica Sadun wrote:
>
> https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md
>
> It's dangerous to go alone. Take this with you.
>
> -- E
>
>
> On May 22
What do you guys think about aliasing the type of the current object with
the Self keyword?
E.g. instead of writing
class Test {
static var value = 0
func printValue() {
print(Test.value)
}
}
One could write
class Test {
static var value = 0
func printValue() {
print(Self.v
Howdy,
I think that the SignedNumberType should implement a method called sign
that will return -1 for negative numbers, 0 for 0 and 1 for positive
numbers. This is similar to the signum method in e.g. Java and similarly
called methods in other languages.
The implementation is fairly straight forw
> If you pass an out-of-range argument, you should reject it using a
precondition
Different use case. I have a circular buffer.
> . And if for some reason you really *do* want to force the value into the
range, clamping it to the bounds of the range seems like a more sensible
solution than modulo
ergonomics.
> >
> >
> >
> > On Sat, May 21, 2016 at 1:44 PM, Leonardo Pessoa
> wrote:
> >>
> >> Adam, I think this is a very particular case and not something that
> needs
> >> to be added to the language. As you pointed out this al
out this already can be
> implemented using resources already available in the language when needed.
>
>
>
> On 21 May 2016 at 17:22, Adam Nemecek via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hello,
>>
>> I think that Swift cou
Hello,
I think that Swift could use the 'double modulo' operator which is for
example in CoffeeScript (some discussion can be found here
https://github.com/jashkenas/coffeescript/issues/1971).
This operator, unlike normal modulo, takes sign from the divisor, not the
dividend e.g. -10 % 3 == -1, b
34 matches
Mail list logo
