> On Jul 6, 2016, at 9:54 AM, Alexey Komnin via swift-users
> wrote:
>
> Here is the code:
>
>let a: String = "abc"
>let b: NSString = "abc"
>
>assert(a == b)
>assert(a.hashValue == b.hashValue, "a.hashValue(\(a.hashValue)) !=
> b.hashValue(\(b.hashValue))")
There's no proble
on Wed Jul 06 2016, Austin Zheng wrote:
> Would this require a swift-evolution review, since it's technically an API
> change? (removing the initializer requirement is something I am also
> interested in seeing...)
Yes.
--
Dave
___
swift-users maili
Would this require a swift-evolution review, since it's technically an API
change? (removing the initializer requirement is something I am also
interested in seeing...)
Austin
On Wed, Jul 6, 2016 at 7:05 PM, Dave Abrahams via swift-users <
swift-users@swift.org> wrote:
>
> on Wed Jul 06 2016, Ti
on Wed Jul 06 2016, Tim Vermeulen wrote:
> RangeReplaceableCollection has three initialisers: init(), init(_:)
> and init(repeating:count:). The latter two are implemented using the
> empty initialiser. But why are these initialisers part of this
> particular protocol? As far as I can tell, no o
The same is true for protocols such as `RandomAccessCollection` and
`MutableCollection`.
> On 6 Jul 2016, at 22:07, Tino Heth <2...@gmx.de> wrote:
>
>
>> I thought this was it, but none of the default implementations of
>> RangeReplaceableCollection seem to use this empty initialiser
> I haven
The best way I know of is the swift-ide-test tool, and you’ll see it being
invoked by many of the ClangImporter tests.
> On Jul 6, 2016, at 10:45 AM, Ryan Wilson via swift-users
> wrote:
>
> Hi everyone,
>
> In Xcode, I can generate a Swift interface for an Objective-C file by using
> the as
I have the same misgivings. The other day, I was wanted to add a piece
of metadata to a Slice type conforming to RangeReplaceableCollection
(coming from the containing collection) but couldn't figure out a way to
make it safe with the empty initializer. It's bugged me a few times
similarly.
Cheer
Hi everyone,
In Xcode, I can generate a Swift interface for an Objective-C file by using
the assistant editor and selecting "Generated Interface" from the menu of
what to display. How would I go about generating this using the tools in
the Swift repo from GitHub? I've been digging around the code
> I thought this was it, but none of the default implementations of
> RangeReplaceableCollection seem to use this empty initialiser
I haven't worked with RangeReplaceableCollection yet, but I wasn't speaking of
how the protocol is used in the libraries, but by "regular users":
class Factory {
I thought this was it, but none of the default implementations of
RangeReplaceableCollection seem to use this empty initialiser (except for the
two other initialisers and `removeAll(keepingCapacity:)`, the latter of which
can be implemented using `removeSubrange(_:)` instead). This makes me wond
> On Jul 6, 2016, at 9:54 AM, Alexey Komnin via swift-users
> wrote:
>
> Here is the code:
>
>let a: String = "abc"
>let b: NSString = "abc"
>
>assert(a == b)
>assert(a.hashValue == b.hashValue, "a.hashValue(\(a.hashValue)) !=
> b.hashValue(\(b.hashValue))”)
Try comparing
Hi there,
> The requirement of the empty initialiser makes it impossible to have a
> collection conform to this protocol that needs additional data for its
> initialisation.
But if there is no guarantee for an empty initializer, you always need a piece
of data to create an instance — and when y
Yes, that is what I thought too. But when I try to do it, I get this error:
Error:(57, 23) 'Self' is only available in a protocol or as the result of
a method in a class; did you mean 'AppEvent’?
Thanks,
Jon
On 7/5/16, 12:15, "swift-users-boun...@swift.org on behalf of Kenny Leung
via swift-u
> On Jul 6, 2016, at 8:55, Neil Faiman wrote:
>
> It’s actually more complicated than that.
>
> case (0, 0): is a tuple-pattern, so its interpretation is well defined. case
> int_1_1: must be an expression-pattern, since it does’t match any of the
> other pattern kinds. So it should compare t
I am not a software scientist. I have to explain things with examples. For
example, in Framework headers.
extension Array : RangeReplaceableCollection {
> /// Creates a new, empty array.
> ///
> /// This is equivalent to initializing with an empty array literal.
> /// For example:
On Wed, Jul 6, 2016 at 9:54 AM, Alexey Komnin via swift-users
wrote:
> Here is the code:
>
> let a: String = "abc"
> let b: NSString = "abc"
>
> assert(a == b)
> assert(a.hashValue == b.hashValue, "a.hashValue(\(a.hashValue)) !=
> b.hashValue(\(b.hashValue))")
>
> It fails with err
I wouldn’t expect String and NSString to have identical implementations of
hashValue(). Is there a problem you’re having that this example is meant to
illustrate? I can see this being an issue if you’re building your own
collection type for strings.
Jeff Kelley
slauncha...@gmail.com | @Slaunc
Here is the code:
let a: String = "abc"
let b: NSString = "abc"
assert(a == b)
assert(a.hashValue == b.hashValue, "a.hashValue(\(a.hashValue)) !=
b.hashValue(\(b.hashValue))")
It fails with error:
assertion failed: a.hashValue(4799450059707601744) != b.hashValue(516202353)
P
I never said a RangeReplaceableCollection shouldn’t be empty. I just think it’s
strange that it requires an empty initialiser (while the Collection protocol
doesn’t).
> On 6 Jul 2016, at 16:33, Zhao Xin wrote:
>
> No. You didn't catch what I meant. I meant it should be like an equation.
> I
It’s actually more complicated than that.
case (0, 0): is a tuple-pattern, so its interpretation is well defined. case
int_1_1: must be an expression-pattern, since it does’t match any of the other
pattern kinds. So it should compare the value of the pattern expression
case_1_1 against the valu
Another option is to rename them manually:
typedef NS_OPTIONS(NSInteger, FoodType)
{
dairyFood NS_SWIFT_NAME(dairy) = 1 << 0 ,
meatFood NS_SWIFT_NAME(meat) = 1 << 1 ,
mushroomFood NS_SWIFT_NAME(mushroomMushroom) = 1 << 2
};
On Wed, Jul 6, 2016 at 6:03 AM, Matteo via swift-users <
It'd be nice if there was a predefined macro to let you know if you're
inside of the header generation machinery. Last time I grazed the compiler
it didn't set up any custom symbols in the preprocessor it uses for the
first stage of processing the generated header. (rdar://27195567 - would
like a
The section you are referencing is regarding ‘assignment’; however, in the
example below we aren’t talking about assignment, this is
'constant-declaration', which is different than a ‘parenthesized expression’.
But overall I get it, and I think I’m trending toward the same conclusion you
reache
The language reference says that “Assignment is performed from each part of the
value to the corresponding part of the expression. A String value can be
assigned to a String, and a () -> Int value can be assigned to a () throws ->
Int, so one would reasonably expect that both tuple assignments w
N
o. You didn't catch what I meant. I meant it should be like an equation.
If foo is a
RangeReplaceableCollection,
foo
minus
foo
equates zero, zero means an empty collection. Both side of the equation
should be with the same unit, the unit is
RangeReplaceableCollection.
Below code also sho
You wouldn’t need an empty initialiser to remove all elements from a
collection, right? You could just use `replaceRange` instead.
> Now I understood you concerns. Have you ever thought of if a non-empty
> RangeReplaceableCollection being removed all of its elements, which makes the
> collectio
I’m not convinced that I see this as a bug, maybe more of a feature request?
The test given seems to be conflating a tuple-type with tuple-pattern…
Shane
> On Jul 5, 2016, at 6:16 PM, Neil Faiman via swift-users
> wrote:
>
> SR-1993.
>
>> On Jul 5, 2016, at 4:15 PM, Jordan Rose wrote:
>>
Aaron this works for me in both Swift 2.2 and Swift 3 provided that you remove
the ‘throws’ keyword.
What seems odd to me is not the first assignment, but rather the second that
_allows_ the use of ‘throws’ when t.1 (i.e. f) does not throw - is your concern
the same?
Shane
On Jul 5, 2016, at
Now I understood you concerns. Have you ever thought of if a non-empty
RangeReplaceableCollection being removed all of its elements, which makes
the collection to be an empty collection. That shouldn't change the
RangeReplaceableCollection
to be a non-RangeReplaceableCollection. So the empty collec
I’m not allowing generic subscripts. The collection is declared as
`AnyIndexArray` and it
can be subscripted with type `Index`.
Either way, it’s not really important. I’m mostly wondering why
RangeReplaceableCollection needs an empty initialiser.
> Then how you defined the index to conform toS
Then how you defined the index to conform to Strideable? Below code does
work as it seams that you can't use generics in subscripts.
subscript(index:T) -> Element
Zhaoxin
On Wed, Jul 6, 2016 at 8:32 PM, Tim Vermeulen wrote:
>
> On 6 Jul 2016, at 14:03, Zhao Xin wrote:
>
> According to the do
> On 6 Jul 2016, at 14:03, Zhao Xin wrote:
>
> According to the document of Swift 3, Array has already conformed protocol
> RangeReplaceableCollection.
That’s exactly why I also want to conform my wrapper to that protocol? I think
there’s a misunderstanding. I’m making a collection that can b
It seems like Swift has broken a lot of the export functionality. Some of
the exporting system was actually a bug but resulting in useful
functionality (i.e like importing C Macros as enums). But once fixed we
lost a lot of it.
*___*
*James⎥Head of Trolls*
*ja...@
According to the document of Swift 3, Array has already conformed
protocol RangeReplaceableCollection.
Zhaoxin
On Wed, Jul 6, 2016 at 7:09 PM, Tim Vermeulen via swift-users <
swift-users@swift.org> wrote:
> RangeReplaceableCollection has three initialisers: init(), init(_:) and
> init(repeating:
> On 5 Jul 2016, at 18:21, Jordan Rose wrote:
>
> Longstanding bug, rdar://problem/17277899 .
> Surprisingly few people have asked for it.
>
> Jordan
>
Good to know, thanks.
Maybe not enough people know/care about the overheads of weak references?
Since the WWDC Swift performance talk I’ve
RangeReplaceableCollection has three initialisers: init(), init(_:) and
init(repeating:count:). The latter two are implemented using the empty
initialiser. But why are these initialisers part of this particular protocol?
As far as I can tell, no other methods of this protocol depend on these
in
Suppose I have an existing enum in Obj-C such as:
typedef NS_OPTIONS(NSInteger, FoodType)
{
dairyFood = 1 << 0,
meatFood= 1 << 1,
mushroomFood = 1 << 2
};
I want to rename all the values so that swift code can use the shorter names.
i.e
typedef NS_OPTIONS(NSInteger, FoodType)
37 matches
Mail list logo
