Date: Tue, 19 Mar 2024 14:55:39 -0300
For what it's worth, I strongly disagree with "s[i, j] seems actively bad".
I think the level of confusion with this syntax will be minimal. I would be
very surprised if developers try to "multi-index" into a string (which
doesn't even make sense) and are surprised that it doesn't work.
Several operations in C++ have the same syntax and slightly different
meanings. And several operations have drastically different meaning (like
operator * and multiplication).
Another example is operator/ for std::filesystem::path. I don't recall
seeing angry developers complaining that / is not dividing their path but
appending.
It's all about the context.
Best Regards,
Breno G.
On Tue, Mar 19, 2024 at 2:09 PM Barry Revzin via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Tue, Mar 19, 2024, 4:36 AM Zhihao Yuan via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Monday, March 18th, 2024 at 7:59 AM, Jonathan Wakely via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>
>> >
>>
>> > I assume the suggestion is that it would be confusing for matrix[x,y]
>> > to return an element of the matrix, but str[i,j] to return a slice of
>> > the string. It would be using the same syntax for two different
>> > things.
>>
>> I considered this syntax but did not suggest
>> it for the same reason. Moreover, unlike
>> Python or MATLAB, we don't have a syntax for
>> implied bounds (s[i:] and s[:j]), so s[i, j]
>> doesn't buy you much.
>>
>> --
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>>
>
> If we can actually spell this s[i:j] (and as Zhihao points out also s[:j]
> and s[i:]), then I think that's worth pursuing and useful. In this context,
> I think "j" is very clearly a position rather than a length.
>
> But just adding a s.slice(i, j) that looks identical to s.susbtr(i, j)?
> Doesn't seem worth it. s[i, j] seems actively bad - you can slice
> multi-dimensional arrays too, so using identical syntax for slicing and
> indexing isn't a good idea.
>
> Barry
>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
I think the level of confusion with this syntax will be minimal. I would be
very surprised if developers try to "multi-index" into a string (which
doesn't even make sense) and are surprised that it doesn't work.
Several operations in C++ have the same syntax and slightly different
meanings. And several operations have drastically different meaning (like
operator * and multiplication).
Another example is operator/ for std::filesystem::path. I don't recall
seeing angry developers complaining that / is not dividing their path but
appending.
It's all about the context.
Best Regards,
Breno G.
On Tue, Mar 19, 2024 at 2:09 PM Barry Revzin via Std-Proposals <
std-proposals_at_[hidden]> wrote:
>
>
> On Tue, Mar 19, 2024, 4:36 AM Zhihao Yuan via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> On Monday, March 18th, 2024 at 7:59 AM, Jonathan Wakely via Std-Proposals
>> <std-proposals_at_[hidden]> wrote:
>>
>> >
>>
>> > I assume the suggestion is that it would be confusing for matrix[x,y]
>> > to return an element of the matrix, but str[i,j] to return a slice of
>> > the string. It would be using the same syntax for two different
>> > things.
>>
>> I considered this syntax but did not suggest
>> it for the same reason. Moreover, unlike
>> Python or MATLAB, we don't have a syntax for
>> implied bounds (s[i:] and s[:j]), so s[i, j]
>> doesn't buy you much.
>>
>> --
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>>
>
> If we can actually spell this s[i:j] (and as Zhihao points out also s[:j]
> and s[i:]), then I think that's worth pursuing and useful. In this context,
> I think "j" is very clearly a position rather than a length.
>
> But just adding a s.slice(i, j) that looks identical to s.susbtr(i, j)?
> Doesn't seem worth it. s[i, j] seems actively bad - you can slice
> multi-dimensional arrays too, so using identical syntax for slicing and
> indexing isn't a good idea.
>
> Barry
>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-03-19 17:55:52