> On 03-Aug-2016, at 10:02 AM, Chris Lattner wrote:
>
> Right. In the future we will probably add the ability to put explicit
> alignment/layout information on structure fields. This would be useful for
> this, as well as other cases where you’re trying to match a specific layout
> used in a
> On Aug 1, 2016, at 9:12 AM, Dmitri Gribenko via swift-users
> wrote:
>
> On Mon, Aug 1, 2016 at 4:20 AM, KS Sreeram via swift-users
> wrote:
>> Hello
>>
>> Is it possible to declare Swift structs that have C compatible memory
>> layout?
>
> The only supported way to do this is to declare y
> On Aug 2, 2016, at 8:44 PM, Tino Heth via swift-users
> wrote:
>
> * yes, an embedded "address"-struct would be an alternative — but copy &
> paste or writing everything in assembler is an alternative as well ;-)
The other alternative for this particular case is a Person protocol which
Cust
> 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 m
Hey Saagar,
I installed Xcode 8 beta 4 and I installed the 2016-07-29 swift development
snapshot, i.e. swift 3 toolchain
Xcode 7.3.1 shows me the toolchain but will not allow me to select it. Xcode 8
does allow me to select it.
So, there we are: the download section on swift.org was accurate,
I don’t think it makes sense to do this. A protocol cannot control how a
particular property is implemented (stored or computed), and any conforming
type must initialize all of its stored properties before returning from its own
initializer. (You can’t write an initializer in a protocol that doe
Oh, it's a computed property! Got it, I thought you meant its value was
computed in the init and never changed again.
Sent from my iPhone
> On Aug 2, 2016, at 19:01, Rick Mann wrote:
>
> It complains if I make it a let because computed properties must be var.
> Because it's a protocol, it can
on Tue Aug 02 2016, Rick Mann wrote:
>> On Aug 2, 2016, at 13:07 , Dave Abrahams via swift-users
>> wrote:
>>
>>
>> on Mon Aug 01 2016, Rick Mann wrote:
>>
>
On Aug 1, 2016, at 19:18 , Jack Lawrence wrote:
Jens: Why? There are significant benefits to value semantics for
>>
on Tue Aug 02 2016, Travis Griggs wrote:
> Chapter 1:
>
> Coming from a Smalltalk background, I was enjoying added all kinds of
> properties to basic number types, for example:
>
> extension Double {
> var rounded:Double {
> return round(self)
> }
> }
>
> Chapter 2:
>
> I upgrad
It complains if I make it a let because computed properties must be var.
Because it's a protocol, it can't be stored (even though it can be stored in
the conforming type).
If I make it { get }, I can't set it in the extensions init() method.
I guess I could make it private set (not sure of the
If I understand things correctly, you *can* make uuid a let because you’re
allowed to set them (once) during init functions.
- Dave Sweeris
> On Aug 2, 2016, at 6:22 PM, Rick Mann via swift-users
> wrote:
>
> I'm trying to define a protocol that has a read-only, immutable member "uuid"
> tha
I'm trying to define a protocol that has a read-only, immutable member "uuid"
that can be set in the init() method, but I'm having trouble. I have this:
protocol
Element
{
var uuid : { get }
}
extension
Element
{
init(...)
{
self.uuid = ...
}
}
I can't make it let, becau
> On Aug 1, 2016, at 5:28 PM, Rick Mann via swift-users
> wrote:
>
> It sure seems natural.
>
> Is there some reason the language can't allow a sub-struct to add member
> variables, such that the whole is treated like a contiguous set of members?
Class-style inheritance is tied to identity.
> On Aug 2, 2016, at 4:03 AM, Tino Heth via swift-users
> wrote:
>
> 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 fund
> On Aug 2, 2016, at 07:48 , Karl wrote:
>
>
>
>> * Structs have statically-dispatched methods and properties; there's no
>> ability to override.
>>
>
> I wonder if that is an inherent property of structs, or a side-effect from
> them having no inheritance. There is no way to define someth
> On Aug 2, 2016, at 13:07 , Dave Abrahams via swift-users
> wrote:
>
>
> on Mon Aug 01 2016, Rick Mann wrote:
>
>>> On Aug 1, 2016, at 19:18 , Jack Lawrence wrote:
>>>
>>> Jens: Why? There are significant benefits to value semantics for
>>> this type of problem, for the reasons laid out i
Chapter 1:
Coming from a Smalltalk background, I was enjoying added all kinds of
properties to basic number types, for example:
extension Double {
var rounded:Double {
return round(self)
}
}
Chapter 2:
I upgraded to XCode8Beta4 yesterday and firstly got to change all of
UICol
on Mon Aug 01 2016, Rick Mann wrote:
>> On Aug 1, 2016, at 19:18 , Jack Lawrence wrote:
>>
>> Jens: Why? There are significant benefits to value semantics for
>> this type of problem, for the reasons laid out in the WWDC
>> videos. It would be helpful to know why you disagree in this
>> case—m
Makes sense. Thanks. :-)
Dave
> On Aug 2, 2016, at 12:24 PM, Jordan Rose wrote:
>
> That was pretty much the rationale for restoring “NS". :-)
>
>> On Aug 1, 2016, at 14:46, Dave Reed via swift-users
>> wrote:
>>
>> Ah, I thought there was already a value type AttributedString that I was no
That was pretty much the rationale for restoring “NS". :-)
> On Aug 1, 2016, at 14:46, Dave Reed via swift-users
> wrote:
>
> Ah, I thought there was already a value type AttributedString that I was now
> using.
>
> Thanks,
> Dave Reed
>
>> On Aug 1, 2016, at 5:35 PM, Shawn Erickson wrote:
>
> * Structs have statically-dispatched methods and properties; there's no
> ability to override.
>
I wonder if that is an inherent property of structs, or a side-effect from them
having no inheritance. There is no way to define something else which also “is”
a CGRect, so all structs are fina
Thanks.
Zhaoxin
On Tue, Aug 2, 2016 at 8:29 PM, David Hart wrote:
> If you are only building application bundles for Darwin platforms, have no
> interest in server Swift, you don’t *need* to look into SPM for now. But as
> its going to be part of Xcode soon, and if you want to help shape into
>
If you are only building application bundles for Darwin platforms, have no
interest in server Swift, you don’t *need* to look into SPM for now. But as its
going to be part of Xcode soon, and if you want to help shape into something
you would be interested it, its always worth looking at it now.
Is Swift Package Manager, SPM, the competitor to Xcode packaging? Or is it
the future of Xcode packing? If it is, when will it be put into Xcode?
Also, what are the differences between built packages and Apple provided
frameworks? Are they just the same thing with different names?
Zhaoxin
__
Imho CFooBridge is unnecessary, bridging code can be added to CFoo itself.
For example, in CCurl some methods which can't be called directly from Swift
have additional wrappers in shim.h:
https://github.com/IBM-Swift/CCurl
In module.modulemap shim.h is used instead of system header,
and the syste
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
Oops, forgot to finish a sentence:
> On Aug 2, 2016, at 1:24 AM, Brent Royal-Gordon wrote:
>
> This makes them small and fast, which are necessities if we're to use them to
> implement fundamental data types like `Int`. Basically, if structs weren't
> already so "primitive",
we would need to
> On Aug 1, 2016, at 5:28 PM, Rick Mann via swift-users
> wrote:
>
> It sure seems natural.
>
> Is there some reason the language can't allow a sub-struct to add member
> variables, such that the whole is treated like a contiguous set of members?
Structs are very "raw":
* There is no extra o
Thanks, Karl, that's great!
In the end, I think I need to use classes, because I do have reference
semantics in my model (e.g. a part definition can be referenced by multiple
instances).
But this helps me get my head around the techniques. Thanks!
> On Aug 1, 2016, at 21:39 , Karl wrote:
>
>
Thanks Joe!
Does this mean NSJSONSerialization in Foundation will now work with native
Swift dictionaries/arrays? That would be a great if so.
Honza
On Tue, Aug 2, 2016 at 1:05 AM Joe Groff via swift-users <
swift-users@swift.org> wrote:
> I've also posted the document as a gist, to gather upda
30 matches
Mail list logo
