> 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
> 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
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
> 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
> 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
> 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
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
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
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
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
> 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
> 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
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
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
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
> …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
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
> 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
> 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
> 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,
> 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
21 matches
Mail list logo
