On Monday, 20 December 2021 at 11:04:00 UTC, Dennis wrote:

Yes, I agree with this. When I use "in" in Python I am very much aware that it does a linear scan, but it is a very useful shorthand that can replaces a long and confusing sequence of or-expressions.

E.g.

if keyword in ['if', 'while', 'for]

is a very useful and clear syntactical construct.

On Monday, 20 December 2021 at 13:54:56 UTC, Ola Fosheim Grøstad wrote:

if keyword in ['if', 'while', 'for]

import std.algorithm.searching;

if (["if", "while", "for"].canFind(keyword)) {
    // ...
}

On Monday, 20 December 2021 at 14:21:08 UTC, Paul Backus wrote:

if keyword in ['if', 'while', 'for]

import std.algorithm.searching;

if (["if", "while", "for"].canFind(keyword)) {
    // ...
}

TBH, for that particular case, this looks nicer, and IMO documents the intent better than the original Pythonism:

import std.algorithm.comparison : among;

if (keyword.among("if", "while", "for")) { /* ... */ }

It also doesn't let work go to waste, as it returns a 1-based index.

On Monday, 20 December 2021 at 13:07:40 UTC, Biotronic wrote:

Thanks, that's an illuminating example.

On Monday, 20 December 2021 at 14:21:08 UTC, Paul Backus wrote:

import std.algorithm.searching;

if (["if", "while", "for"].canFind(keyword)) {
    // ...
}

You can always create a library construct, but then you should also argue in favour of removing AAs and "in". You either do it, or you don't. Why the half-measures?

On Monday, 20 December 2021 at 21:11:28 UTC, Ola Fosheim Grøstad wrote:

import std.algorithm.searching;

if (["if", "while", "for"].canFind(keyword)) {
    // ...
}

There are a lot of features one could potentially add to D to improve it, and limited resources to devote to doing so. I'm not necessarily against adding in for slices, but since we already have a perfectly good library solution, I don't think it deserves a high priority.

Feel free to write the DIP yourself if you disagree. :)

On 12/20/21 6:04 AM, Dennis wrote:

One thing not really being discussed is that there is a difference between "some library" defining slow in operators, or slow opIndex, and dlang/Phobos doing it.

D picked the path of trying to ensure complexity consistency for in, but it's more of a stylistic rule, not necessarily a requirement.

-Steve

On 12/19/21 2:34 PM, Ola Fosheim Grøstad wrote:

Please see existing research, this is not a new concept.

-Steve

On Monday, 20 December 2021 at 21:11:28 UTC, Ola Fosheim Grøstad wrote:

No, canFind and among search for a given value in a range. in checks if a given key exists and returns a pointer to the associated data (not a pointer to the matching key). This is why Phobos SortedRange does not implement opIn even though it would be sub-linear. Dennis is right that conceptually a key for an array is an index. An array element value is the data associated with an index.

On Tuesday, 21 December 2021 at 17:02:22 UTC, Steven Schveighoffer wrote:

What do you mean by research, this is a trivial topic. In order to get O(1) amortised you have to delay shrinkage, you must prove that any possible sequence does not reallocate more frequently than N operations.