Re: [swift-users] struct property changing calls didSet of the Struct each time, but class won't
> My code depends on the class version didSet but I used the struct version. It > took me a long time to debug this out. Is this a knowledge that has been well > known already? Yes, that’s how it’s supposed to be. It’s a feature of struct which isn’t available with classes (so considering the Objective-C past, the „surprise“ is actually that didSet is called when you do that change to a struct property).___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] any wisdom about sharing "common" overloads/extensions in base libraries?
> This is not a made up situation: many people even within one company trying > to share code somewhat informally are going to write the same code to make > using CGPoint/Size/Rect easier, and now we can’t share anything safely. Well, have a look at what C++ did: Nothing ;-) — and therefore, the world is littered with incompatible, trivial definitions of vectors, images, notes… My favourite example are quaternions (just do a search for that term in Apples own frameworks…), so there is definitely an issue here. The solution is quite easy, but that makes things really complicated: Just declare a standard (that's easy — so everyone wants to have his own one ;-). Unless someone with outstanding reputation (sadly, Apple seems not to care for this) starts a project like Boost, we'll have to live with incompatibilities. Tino___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] for in? optionalCollection {
This one started over at swift-users, with a question on how to deal with
looping over containers that may be nil.
Imho the beauty of the feature is that it's simple enough to be explained in
the subject line, but here is the "long" story:
let test: [Int]? = nil
// this is possible now
if let test = test {
for i in test {
print(i)
}
}
// how it could be written with a modified keyword
for i in? test {
print(i)
}
I've been thinking "in?" had been brought up long ago, but as I haven't found
such a proposal, I probably confused it with the cancelled plan to write one on
my own (or I just was to stupid to search ;-).
Syntactic sugar like this is definitely nothing that has priority now, but
discussing it shouldn't be a big distraction — and if it turns into a proposal
that as well survives review, it might be even simple enough to act as a
trigger for me to finally get my hands on some real work for Swift ;-)
- Tino___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] for with optional collection?
> Is there any concise way to write the following?
>
> if let collection = someOptionalCollection
> {
>for item in collection
>{
>}
> }
I've been thinking about that lately, but haven't had the time to look wether
someone on evolution already proposed a "for in?"-loop…
Imho the "forEach" solution is flawed, because you can't break the loop, and
the "?? []" isn't perfect either:
I hope the compiler can optimise so that the assembly is as fast as the "if
let" solution, but even if this is the case, it is not obvious for a human
reader.
This
extension Optional where Wrapped: Sequence {
var elements: [Wrapped.Iterator.Element] {
switch (self) {
case .none:
return []
case .some(let o):
return Array(o)
}
}
}
let test: [Int]? = nil
for i in test.elements {
print(i)
}
looks nice to me (except the return type — I guess there are better options),
but I don't expect that the compiler can do much to optimise it.
for i in? test {
print(i)
}
Imho looks even better, but this would need an extension of the language itself…
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse
> Easy explained - The problem rises indeed not from the added features but > from the fp group that imposes it’s usage in the Standard libraries and “the > swifty way”. I like many features of Swift (or I wouldn’t be here) but I > don’t want to live in Haskel world. And for some reason these guys become > more and more influential in the community. I personally see functional programming as a useful tool that avoids some hard problems, but I have to agree that there is an unhealthy hype about it. It is quite common among developers to overuse "new" (fp itself is quite old) toys, and that's ok — but there are definitely some people who are pushing hard against established concepts like OO, in the deep belief their opinion is the only truth, and that everything else should be abolished. I think it's bad for the spirit of the community when members think that way, and even state that those who don't agree with their personal interpretation about what's "swifty" should leave. That's one reason I don't like the adjective "swifty", but afaics, those who actually decide about the future of Swift have no plans to encourage certain styles by crippling the alternatives. Imho the goal should be improvement for everyone: Those who like fp, those who like POP, those who like OO… and, of course, for those who like mailing list, as well as for those who hate them.___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] [swift-evolution] Plan to move swift-evolution and swift-users mailing lists to Discourse
Great news — and I guess it's a plus that Discourse isn't PHP but Ruby, as I expect there are quite a lot Rubyists around here. So, hopefully the issues that might exist (especially with the mail interface) can be addressed to make everyone happy. Although Discourse looks like a really good fit, I would be interested to hear about other forum solutions as well: It would be a pity if we choose based on popularity only, ignoring alternatives completely just because they aren't that trendy. - Tino Anyone interested in starting to write a (possible) long-term solution using server-side Swift? Imho the challenge doesn't look that hard, and I've already been thinking about starting such a toy project to dive into the topic... ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Swift 101: JSON or XML?
It's no real help for you, but for me, XML is a document format (store data for a long time), whereas JSON is a transfer format (I really wouldn't prefer JSON over XML for archiving). But imho JSON won't continue growing in popularity, because finally people seem to rediscover the advantages of binary formats (Protobuf, FlatBuffer… but unless performance isn't critical, I'd probably stick with JSON as well). ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] How to rewrite this snippet without `existentials`?
> Thanks, that works party as needed but I just realize this main idea here is > exactly an example where one would need generic protocols That's right — and I guess they rank quite hight on the general evolution-wishlist ;-)___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Dealing with loss of observers on protocol properties with default implementations
> I find this to be an ugly solution. Particularly so since non-objc protocols > don't support optional members. Compare this to using a base class: If inheritance works well, I wouldn't insist on protocols just for the sake of it. This wont help with structs, but your example uses a class… and if you can't use inheritance for other reasons, you could try composition instead.___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Extending Arrays of specific type, and specialization
Hi Rick,
as evolution is somewhat paused, swift-users seems to gain more traction ;-)
Imho the most natural would be
extension Array {
…
}
I hope to see this addition included when the topic is discussed again.
- Tino
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] The value of enums
> …oh, I just realized we’re on -users not -evolution here. :-) Core found an effective way to limit the distractions from evolution: Over there, this would have been a proposal to remove enums [with associated objects] in favor of union types ;-) Tino Joking aside, imho it's a pity that all those fundamental discussions from the early times can't be published — I bet ideas like "everything is an expression" have been brought up, and the reason for their rejection could really help understanding the big picture of the language.___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] The value of enums
Enums are a fundamental part of Swift, so I guess they won't change much — but I wonder if anyone shares my observations in real-life use… Afair, there are three different types of enums: - Enums with raw values - enums with associated objects - Plain enums (no underlying value) I use the first type quite often (as a convenient way to create string constants, or for serialization), but see no real value in plain enums (they offer nothing over enums backed with a raw value). The second type is special: It looks like a really cool concept, and and I started several designs based on them — just to realize later that structs and classes are a better fit. My conclusion so far is that enums perform bad as soon as you want to attach additional data or behavior; one or two computed properties are ok, but those switch-statements quickly become a burden. There are some options to work around this problem, but I guess I'll just stay away from enums with associated objects by default (with the exception of error-types — imho those can be modeled quite nicely). So, that's my current perception, and I'm curious if others had similar experiences — or, even more interesting, completely different observations and elegant solutions based on enums. - Tino ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Performance critical code in Swift
My general advice for performance critical code (especially when it's about stuff like serialization and parsing): If you just want a working solution without spending much time, stick with C. Swift can be fast, but it's harder to write slow code in C. If, on the other hand, coding time is no big concern: Use Swift, try to get it as fast as possible (can take time) — and if this isn't enough, switch to C (which might end up to be to slow as well ;-) - Tino ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Why can't structs inherit from other structs?
> Protocols currently require you to redeclare their properties, but we could > add a feature to change that if there was a strong enough justification. Sometimes, this would be very handy (not only for structs) — but I'd expect that there are at least as many cases where you don't want that behavior… It would be possible to silently generate readwrite-properties (and even functions returning void or an optional), but that feels a little bit to much magic for me. Also, this would be a use-case for protocols that is completely different from their normal role. ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Why can't structs inherit from other structs?
> I thought the problem with struct polymorphism (specifically the stack size > issue) *was* the fundamental reason we can’t have “substructs”. As I said: I guess this is the reason we don't have "substructs" now — but inheritance can be useful without polymorphism: Imagine an application that managers data of customers and employees. It would be reasonable to model those data-containers as structs, and as both structs share many properties, a "person"-type would be quite convenient, even if it is not possible to create collections which contain customers as well as employees*. Tino * yes, an embedded "address"-struct would be an alternative — but copy & paste or writing everything in assembler is an alternative as well ;-)___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Why can't structs inherit from other structs?
There is no fundamental reason to disallow struct inheritance, and I started a pitch where afair one member of core agreed it would be useful — I hope there is time to add it in the next year. There is, however, a fundamental problem with struct polymorphism: As soon as you add members, you loose compatibility (a Point3D: Point2D can't be stored or passed where its parent is expected), and when you cross module borders, there might be issues as well. Struct and class have to behave different in inheritance, and to disallow struct subtyping completely is just the easiest solution. Imho it's definitely not the best solution, as it forces you to use classes whenever you want to use inheritance (I don't think that composition is superior in general). It could be even possible to create structs that inherit from classes and vice versa. Tino ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Parsing binary data
> It should be simple: use Array for your data. Doing data-processing in big blocks often improves performance, and when I checked the effect of a very small buffer, it was quite significant. But arrays are no option for me, because my data isn't structured that way: It's a stream of different elements (timestamp, type, and a payload that depends on the type), so I have evaluate byte-by-byte… But it seems I'm lucky, because the next format fits well into arrays :-). I guess I'll give it a try, and I'll share my insights here if they are worth it (most likely, I won't write a comparison implementation in C if Swift is fast enough…) Thanks, Tino ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
[swift-users] Parsing binary data
Hi there! Some weeks ago I wrote a parser for a binary format, but it's performance was disastrous, and I knew how to easily outperform this first approach with Objective-C by large. Now, I'm about to write a different parser, which of course ;-), I'd prefer to code in Swift. Working with raw bytes most likely won't ever be a thing where Swift shines, but I guess there are ways to do so without compromising speed… so, are there any established best-practices and things to avoid? Or is it less hassle to go back to C for low-level stuff? Tino ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] Coding style for internal/private variables
I never liked the underscores (so for me, they have been the best choice to mark stuff I should not know of in Cocoa ;-). For several years, I prefixed instance variables with "m", but stopped doing so after a talk about bad habits in writing Java code: It is like Hungarian notation, which also puts redundant information into names — and if even Java-folks think it's anachronistic… ;-) Objective-C lacked some features that Swift has, so workarounds had been created; but those shouldn't be carried over (by the way: It's similar with file names and those extensions, and a modern file system for OS X is years overdue ;-) ___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] scientific library for swift?
> Of course, duh. I'm interested in what you end up using, as scientific > computing seems to me like a great use case for Swift. imho there is one thing missing to make this a true statement: Fixed size vectors and matrices to do typesafe calculations (the compiler can't warn you when you try to multiply 3x3 with 4x4…) Hope we'll see some sort of limited template support in the future. Tino___ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
Re: [swift-users] scientific library for swift?
> Please NO. Templates are the worst idea ever to evolve from C++. Never let
> this madness enter into Swift, it has done enough damage in the C++ world
> already.
Hey, templates are cool — they are even Turing complete! ;-)
No, I really don't think it's that useful to calculate Fibunacci-numbers at
compile time (at least I don't think C++ template syntax is a good tool to do
so).
But it wouldn't be that hard to implement something in between generics and
full template support, without the dangers (that's what I meant with "limited").
I might write a proposal some day, but the concept isn't that hard:
Right now, we can have something like
let m = Matrix(rows: 3, columns: 4)
easily.
There's just the problem that the compiler cannot deduce which matrices are
"compatible", as there is only one Matrix-type.
If we had a way to tell the compiler that "rows" and "columns" have an effect
on the type, everything would be fine, and this model of compile-time
parameters imho is quite simple:
struct FloatVector {
private var elements = Array(capacity: dimensions)
…
}
let vector = FloatVector<3>(0, 0, 1)
let otherVector = FloatVector<2>(0, 1)
let sum = vector + otherVector // compiler error, type mismatch
I think many problems with template happen because they are not compiled unless
you use them, and compile-time parameters wouldn't suffer from this.
Best regards,
Tino___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
