Reverted. Thanks Doug.
Sent from my iPhone
> On Dec 13, 2017, at 10:54 PM, Douglas Gregor via swift-dev
> wrote:
>
> I’m checking that theory with
>
> https://github.com/apple/swift/pull/13427
>
> and will complete the revert if that PR runs clean.
>
>> On Dec 13, 2017, at 10:08 PM, D
We really don't want to make subscripting a non-O(1) operation. That just
provides false convenience and encourages people to do the wrong thing with
Strings anyway.
I'm always interested in why people want this kind of ability. Yes, it's nice
for teaching programming to be able to split string
Hi,
I'm interested in running Swift on Windows.
I found the document to build the Swift compiler for Windows (
https://github.com/apple/swift/blob/master/docs/Windows.md) and tried it.
I managed to build it with MSVC, but the resulting compiler could not
generate executables run properly.
(The ex
I think there’s a middle ground here as the current API is overly complex
and general. 95% of the time people are dealing with ASCII strings and
don’t care about things like unicode cluster boundaries and whatnot
On Thu, Dec 14, 2017 at 12:13 PM, Jordan Rose via swift-dev <
swift-dev@swift.org> wr
95% ASCII? Even if you forgot the rest of the World and consider only US
this doesn’t seems right.
But of course people (in the general) don’t care about Unicode Clusters.
Because that, we should focus on keep Unicode string manipulation easy,
instead just forget the Unicode rules.
Em qui, 14 de
Not it.
5/21 Test #5: dispatch_group ...***Timeout 30.02 sec
Start 6: dispatch_overcommit
> On Dec 14, 2017, at 3:30 PM, swift...@swift.org wrote:
>
> [FAILURE] oss-swift-4.1-incremental-RA-linux-ubuntu-16_04 [#503]
>
> Build URL:
> https://ci.swift.org/job/oss-swif
perhaps i’m biased because most of the work i do is on strings that are
meant to be machine read and written but if you ask me, user-facing unicode
strings are the special case and it seems the entire API is optimized for
them, and not more common ASCII strings.
On Thu, Dec 14, 2017 at 3:40 PM, Wa
People used to the offset index system instead of the String.Index. Using
offset indices to name the elements, count the elements is normal and nature.
This offset index system has a long history and a real meaning to the
collection. The subscript s[i] has a fix meaning of "getting the i-th elem
> On Dec 14, 2017, at 4:49 PM, Cao, Jiannan via swift-dev
> wrote:
>
> People used to the offset index system instead of the String.Index. Using
> offset indices to name the elements, count the elements is normal and nature.
>
The offset system that you’re referring to is totally available
This offset is unicode offset, is not the offset of element.
For example: index(startIndex, offsetBy:1) is encodedOffset 4 or 8, not 1.
Offset indexable is based on the offset of count of each element/index. it is
the same result of s.index(s.startIndex, offsetBy:i)
The encodedOffset is the unde
for example:
caféz
the offset index of z is always 4. Which means the 4-th character of the
string. You can always use s[s.index(s.startIndex, offsetBy:4)] to access the z.
but the encodedOffset index of z maybe 16 or 20. This is not the offset concept
of the collection, but the encoded offset c
Yes, I was trying to highlight that they are different and should be treated
different. This was because it seemed you were conflating the two in your
argument. You claim that people expect it, and I’m pointing out that what
people actually expect (assuming they’re coming from C or languages wit
Hi All-
First of all, a big thank you to everyone who has provided feedback on our
prototype Discourse forum. Based on the fact that we’re still receiving
feedback, we’d like to move to a slightly less aggressive schedule for our
rollout, in order to make sure that we’ve adequately addressed i
Title: Report
[FAILURE] oss-swift-package-osx [#853]
Build URL:https://ci.swift.org/job/oss-swift-package-osx/853/
Project:oss-swift-package-osx
Date of build:Thu, 14 Dec 2017 21:15:48 -0600
Build duration:2 hr 1 min
Identified problems:Regression test failed: This build
This failed once and then came back with no relevant source changes...
- Doug
> On Dec 14, 2017, at 7:41 PM, swift...@swift.org wrote:
>
> [FAILURE] oss-swift-4.1-incremental-RA-linux-ubuntu-16_10 [#438]
>
> Build URL:
> https://ci.swift.org/job/oss-swift-4.1-incremental-RA-linux-u
15 matches
Mail list logo
