Was thinking on this topic after seeing this: http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d
Still can't understand rationale here. Why native slicing / random access is allowed for narrow strings, but trait explicitly negates this?

On 10/23/12 11:36 AM, mist wrote:
> Was thinking on this topic after seeing this:
> http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d
>
> Still can't understand rationale here. Why native slicing / random
> access is allowed for narrow strings, but trait explicitly negates this?

Historical mistake.

Andrei

On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu wrote:
> On 10/23/12 11:36 AM, mist wrote:
>> Was thinking on this topic after seeing this:
>> http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d
>>
>> Still can't understand rationale here. Why native slicing / random
>> access is allowed for narrow strings, but trait explicitly negates this?
>
> Historical mistake.
>
> Andrei

Is string random access gonna be deprecated some day then or this is considered a mistake we need to get used to? :)

On 10/23/12 11:58 AM, mist wrote:
> On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu wrote:
>> On 10/23/12 11:36 AM, mist wrote:
>>> Was thinking on this topic after seeing this:
>>> http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d
>>>
>>>
>>> Still can't understand rationale here. Why native slicing / random
>>> access is allowed for narrow strings, but trait explicitly negates this?
>>
>> Historical mistake.
>>
>> Andrei
>
> Is string random access gonna be deprecated some day then or this is
> considered a mistake we need to get used to? :)

Walter is unconvinced it's a mistake, which doesn't make it any easier. If I had my way, I'd require people to write str.rep[6] to access the sixth byte in the representation of a UTF-8 or UTF-16 string. It would make D's strings from great to indistinguishable from perfect.

Andrei

On 10/23/12 12:35 PM, Andrei Alexandrescu wrote:
> On 10/23/12 11:58 AM, mist wrote:
>> On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu wrote:
>>> On 10/23/12 11:36 AM, mist wrote:
>>>> Was thinking on this topic after seeing this:
>>>> http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d
>>>>
>>>>
>>>>
>>>> Still can't understand rationale here. Why native slicing / random
>>>> access is allowed for narrow strings, but trait explicitly negates
>>>> this?
>>>
>>> Historical mistake.
>>>
>>> Andrei
>>
>> Is string random access gonna be deprecated some day then or this is
>> considered a mistake we need to get used to? :)
>
> Walter is unconvinced it's a mistake, which doesn't make it any easier.
> If I had my way, I'd require people to write str.rep[6] to access the
> sixth byte in the representation of a UTF-8 or UTF-16 string. It would
> make D's strings from great to indistinguishable from perfect.
>
> Andrei

s/byte/code unit/

Hm, and all phobos functions should operate on narrow strings as if they where not random-acessible? I am thinking about something like commonPrefix from std.algorithm, which operates on code points for strings.

On 2012-10-23, 19:21, mist wrote:

> Hm, and all phobos functions should operate on narrow strings as if they where not random-acessible? I am thinking about something like commonPrefix from std.algorithm, which operates on code points for strings.

Preferably, yes. If there are performance (or other) benefits from
operating on code units, and it's just as safe, then operating on code
units is ok.

-- 
Simen

On 10/23/2012 05:58 PM, mist wrote:
> On Tuesday, 23 October 2012 at 15:55:23 UTC, Andrei Alexandrescu wrote:
>> On 10/23/12 11:36 AM, mist wrote:
>>> Was thinking on this topic after seeing this:
>>> http://stackoverflow.com/questions/13014999/cannot-slice-taker-from-std-range-in-d
>>>
>>>
>>> Still can't understand rationale here. Why native slicing / random
>>> access is allowed for narrow strings, but trait explicitly negates this?
>>
>> Historical mistake.
>>
>> Andrei
>
> Is string  random access gonna be deprecated some day then or this is
> considered a mistake we need to get used to? :)

The other valid opinion is that the 'mistake' is in Phobos because it
treats narrow character arrays specially.
Note that string is just a name for immutable(char)[]. It would have to become a struct if random access was to be deprecated.

On Wednesday, October 24, 2012 00:28:28 Timon Gehr wrote:
> The other valid opinion is that the 'mistake' is in Phobos because it treats narrow character arrays specially.

If it didn't, then range-based functions would be useless for strings in most cases, because it rarely makes sense to operate on code units.

> Note that string is just a name for immutable(char)[]. It would have to become a struct if random access was to be deprecated.

I think that Andrei was arguing for changing how the compiler itself handles arrays of char and wchar so that they wouldn't have direct random access or length anymore, forcing you to do something like str.rep[6] for random access regardless of what happens with range-based functions.

- Jonathan M Davis

On 10/24/2012 01:07 AM, Jonathan M Davis wrote:
> On Wednesday, October 24, 2012 00:28:28 Timon Gehr wrote:
>> The other valid opinion is that the 'mistake' is in Phobos because it
>> treats narrow character arrays specially.
>
> If it didn't, then range-based functions would be useless for strings in most
> cases, because it rarely makes sense to operate on code units.
>
>> Note that string is just a name for immutable(char)[]. It would have to
>> become a struct if random access was to be deprecated.
>
> I think that Andrei was arguing for changing how the compiler itself handles
> arrays of char and wchar so that they wouldn't have direct random access or
> length anymore, forcing you to do something like str.rep[6] for random access
> regardless of what happens with range-based functions.
>
> - Jonathan M Davis
>

That idea does not even deserve discussion.