On Friday, 25 October 2019 at 16:01:57 UTC, mipri wrote:
> On Friday, 25 October 2019 at 15:52:50 UTC, Paul Backus wrote:
>> On Friday, 25 October 2019 at 09:25:21 UTC, Dennis wrote:
>>> I can overload the 'in' operator on my types to something that takes exponential time if I want, just like "+" can also be overloaded to a linear time operation on e.g. BigInt.
>>
>> Worth noting that `opIn` is a D1 operator overload, and thus deprecated as of 2.088.0.
>
> That wasn't mentioned though? Does it reverse the arguments so
> that the writeln() examples below can be more naturally ordered?

I made a mistake reading the language spec and missed `in` in the list of operators covered by opBinary. Please disregard!

On 10/25/2019 02:25 AM, Dennis wrote:
> On Friday, 25 October 2019 at 05:17:35 UTC, Ali Çehreli wrote:
>> - Big O is different
>
> No it isn't.

Agreed and I've just realized a benefit of the 'in' operator for arrays, which I haven't heard before. (I don't follow all discussions in detail.) 'in' can

- linear search on regular arrays

- binary search on SortedRanges

So, this could would better for the programmer. 'in' would pick the fastest option without ever being slower than what the programmer would do. (The programmer can call canFind() on a regular but otherwise sorted array.) However, the following gotcha is still possible:

  auto sorted = sort(arr);
  if (element in arr) { // Oops; actually meant 'element in sorted'
    // ...
  }

I'm still not completely sold on the whole idea though because it's not a clear win.

Do others see other advantages in other places like templates? For example, could templates really be written generically for arrays and associative arrays?

Ali

On Friday, 25 October 2019 at 19:49:05 UTC, Ali Çehreli wrote:
> I'm still not completely sold on the whole idea though because it's not a clear win.
>
> Do others see other advantages in other places like templates? For example, could templates really be written generically for arrays and associative arrays?

I'm personally not concerned about generic code.
- The semantics of `in` aren't very well defined anyways.
- Those who write templates like that (hopefully) know what they're doing, they'll figure it out  ;)
- I can't think of situations where you actually want to write code that generically works on both arrays and associative arrays like that. (Though if anyone knows one, please share, I'm interested.)

I'm more concerned about the repeated reports of users being surprised that `in` doesn't work like they expect. In Python, the expression `3 in [2, 3, 4]` returns a boolean, and in D you can do `bool b = 15 in iota(10, 20)` because the operator is overloaded in Phobos for iota; But as far as actual language support, `in` is only defined for associative arrays:

https://dlang.org/spec/expression.html#InExpression

It returns a pointer which can be used in an if-statement, but also to read/modify the value. So should `in` on arrays do the same? It would be consistent, but usage of raw pointers is discouraged with the advent of scope and ref etc. Also you can't implicitly convert a pointer to a boolean.
Should it be a boolean then? That means part of the result of the linear search is discarded, making `in` less flexible.
So maybe we should leave it for now, and put a small explanation in the error message.

On Friday, 25 October 2019 at 20:44:18 UTC, Dennis wrote:
> On Friday, 25 October 2019 at 19:49:05 UTC, Ali Çehreli wrote:
>> I'm still not completely sold on the whole idea though because it's not a clear win.
>>
>> Do others see other advantages in other places like templates? For example, could templates really be written generically for arrays and associative arrays?
>
> I'm personally not concerned about generic code.
> - The semantics of `in` aren't very well defined anyways.
> - Those who write templates like that (hopefully) know what they're doing, they'll figure it out  ;)
> - I can't think of situations where you actually want to write code that generically works on both arrays and associative arrays like that. (Though if anyone knows one, please share, I'm interested.)
>
> I'm more concerned about the repeated reports of users being surprised that `in` doesn't work like they expect. In Python, the expression `3 in [2, 3, 4]` returns a boolean, and in D you can do `bool b = 15 in iota(10, 20)` because the operator is overloaded in Phobos for iota; But as far as actual language support, `in` is only defined for associative arrays:
>
> https://dlang.org/spec/expression.html#InExpression
>
> It returns a pointer which can be used in an if-statement, but also to read/modify the value. So should `in` on arrays do the same? It would be consistent, but usage of raw pointers is discouraged with the advent of scope and ref etc. Also you can't implicitly convert a pointer to a boolean.
> Should it be a boolean then? That means part of the result of the linear search is discarded, making `in` less flexible.
> So maybe we should leave it for now, and put a small explanation in the error message.

I'm also not so fond of that "in" operator returns a pointer which is bad fit for arrays and possibly many other container algorithms as well. I think the best would be that it would return an optional of type T and T would be user defined. For associative arrays, a pointer or a reference to the element. For arrays the index of that element would suitable. Also overloading would be nice so that "in" operator could return several possible optional types, not sure if that would be possible though.

On Friday, 25 October 2019 at 21:06:53 UTC, IGotD- wrote:
> On Friday, 25 October 2019 at 20:44:18 UTC, Dennis wrote:
>> On Friday, 25 October 2019 at 19:49:05 UTC, Ali Çehreli wrote:
>>> I'm still not completely sold on the whole idea though because it's not a clear win.
>>>
>>> Do others see other advantages in other places like templates? For example, could templates really be written generically for arrays and associative arrays?
>>
>> I'm personally not concerned about generic code.
>> - The semantics of `in` aren't very well defined anyways.
>> - Those who write templates like that (hopefully) know what they're doing, they'll figure it out  ;)
>> - I can't think of situations where you actually want to write code that generically works on both arrays and associative arrays like that. (Though if anyone knows one, please share, I'm interested.)
>>
>> I'm more concerned about the repeated reports of users being surprised that `in` doesn't work like they expect. In Python, the expression `3 in [2, 3, 4]` returns a boolean, and in D you can do `bool b = 15 in iota(10, 20)` because the operator is overloaded in Phobos for iota; But as far as actual language support, `in` is only defined for associative arrays:
>>
>> https://dlang.org/spec/expression.html#InExpression
>>
>> It returns a pointer which can be used in an if-statement, but also to read/modify the value. So should `in` on arrays do the same? It would be consistent, but usage of raw pointers is discouraged with the advent of scope and ref etc. Also you can't implicitly convert a pointer to a boolean.
>> Should it be a boolean then? That means part of the result of the linear search is discarded, making `in` less flexible.
>> So maybe we should leave it for now, and put a small explanation in the error message.
>
> I'm also not so fond of that "in" operator returns a pointer which is bad fit for arrays and possibly many other container algorithms as well. I think the best would be that it would return an optional of type T and T would be user defined. For associative arrays, a pointer or a reference to the element. For arrays the index of that element would suitable. Also overloading would be nice so that "in" operator could return several possible optional types, not sure if that would be possible though.
I argee with your talk, lanuage designer need keep consistent that the 'in' semantics. or not support 'in' key word. Don't assumption that how user use it.