On 05/02/2012 04:01 PM, Andrei Alexandrescu wrote:
> On 5/2/12 6:15 AM, Tobias Pankrath wrote:
>>
>>>
>>> No, it is not an O(1) operation, it is *close* to O(1) (as much sense
>>> as that statement can make). I don't know why you associate any
>>> particular complexity with 'in' in the first place. And I do think
>>> we're crippling the language, considering Python (and probably other
>>> languages) has had this feature since forever.
>>>
>>> I'm seriously worried. It seems to me like we're trying to cater to
>>> people who can't reason about the types in their program and the
>>> complexities of performing various operations on them. Since when did
>>> algorithmic complexity become a reason to take away syntax sugar?
>>
>> +1
>>
>> I do argee. opIn is handy for arrays, too. That the complexity would be
>> linear and thus it should be disallowed is not a valid argument in my
>> opinion, because with the exact same argument you could kick
>> std.algorithm.find out of phobos. It is just obvious to every trained
>> programmer that finding an element in an unordered list takes O(n).
>
> The problem here is making complexity an implementation detail of a
> uniform interface (e.g. over hashes and linear containers). That is fail.
>
> Andrei
>
>

The interface is different:

void main(){
    int[] a = [0,0,0];
    a[2] = 3;
    assert(2 !in a);
}

vs.

void main(){
    int[int] aa;
    aa[2] = 3;
    assert(2 in aa);
}

On 5/2/12 10:20 AM, Timon Gehr wrote:
> The interface is different:
>
> void main(){
> int[] a = [0,0,0];
> a[2] = 3;
> assert(2 !in a);
> }
>
> vs.
>
> void main(){
> int[int] aa;
> aa[2] = 3;
> assert(2 in aa);
> }

The syntactic interface is the same. That would be the semantic interface, which makes the idea twice as bad.

Andrei

On 05/02/2012 05:25 PM, Andrei Alexandrescu wrote:
> On 5/2/12 10:20 AM, Timon Gehr wrote:
>> The interface is different:
>>
>> void main(){
>>     int[] a = [0,0,0];
>>     a[2] = 3;
>>     assert(2 !in a);
>> }
>>
>> vs.
>>
>> void main(){
>>     int[int] aa;
>>     aa[2] = 3;
>>     assert(2 in aa);
>> }
>
> The syntactic interface is the same.

Encapsulation of complexity is a problem if it is not obvious to the programmer. I am not sure it can even be called such if the semantics is different.

> That would be the semantic interface, which makes the idea twice as bad.
>
> Andrei

I tend to agree, but I think that the two points are mutually exclusive.

>> It's hard to grep for (since with is
>> used in comments quite often),
>
> Try to search for "with("  or "with\s(", that are less common in normal text.
>

There is no tool (maybe the compiler could provide such a tool) to remove all comments?

That way, you could do:

cat file.d | tool | grep whatever

On 01/05/12 00:33, Timon Gehr wrote:
> On 04/30/2012 11:28 PM, bearophile wrote:
>> Walter:
>>
>>> The first thing to emphasize is that NONE of this will happen for D2.
>>> The emphasis on D2 is fixing implementation and toolchain issues.
>>> Breaking existing code is off the table unless we are pretty much
>>> forced to in order to fix some other more important issue.
>>
>> But you need to keep into account that D2 is still a not widely used
>> language. So deprecating some things now will cause far less troubles
>> than doing it in D3 some years from now.
>
> D2 -> D3 will be full of breaking changes anyway. Otherwise there is no
> reason to add another major language version.
>

What is this D3 thing ????
As far as I can tell, 'D3' was invented by newcomers to the forums.

On 28/04/12 20:47, Walter Bright wrote:
> Andrei and I had a fun discussion last night about this question. The
> idea was which features in D are redundant and/or do not add significant
> value?
>
> A couple already agreed upon ones are typedef and the cfloat, cdouble
> and creal types.
>
> What's your list?

Other ones which were agreed to a long time ago were:

* NCEG operators

* built-in .sort and .reverse

=============================

About the NCEG operators -- the reason they're redundant is that you practically always want to treat NaN separately.

I've tried _very_ hard to come up with uses for them, but without success.

The thing I've used the most is:
x !<>= x

which is a kind of built-in isNaN(x), but that can also be rewritten as:
x != x

Initially I though you'd do things like

real func(real x)
{
// x must be non-NaN and in the range -x.infinity .. N
  if (x !< N)
      return real.nan;

but even that isn't convincing, because if x is NaN you should be returning x, so that you preserve NaN payloads.

I think I have used these guys more than anyone else, but I still haven't found a single use case that stands up to scrutiny.

On 5/3/12 9:55 AM, Don Clugston wrote:
> On 28/04/12 20:47, Walter Bright wrote:
>> Andrei and I had a fun discussion last night about this question. The
>> idea was which features in D are redundant and/or do not add significant
>> value?
>>
>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>> and creal types.
>>
>> What's your list?
>
> Other ones which were agreed to a long time ago were:
>
> * NCEG operators
>
> * built-in .sort and .reverse

Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out.

One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o).


Andrei

On 03/05/12 16:13, Andrei Alexandrescu wrote:
> On 5/3/12 9:55 AM, Don Clugston wrote:
>> On 28/04/12 20:47, Walter Bright wrote:
>>> Andrei and I had a fun discussion last night about this question. The
>>> idea was which features in D are redundant and/or do not add significant
>>> value?
>>>
>>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>>> and creal types.
>>>
>>> What's your list?
>>
>> Other ones which were agreed to a long time ago were:
>>
>> * NCEG operators
>>
>> * built-in .sort and .reverse
>
> Good ones. In fact I even discounted them from this discussion because
> I'd already considered them gone. Walter agreed that I don't mention
> them in TDPL, with the intent to have them peter out.
>
> One good step right now would be to remove NCEG operators from the
> online documentation. Later on, we'll consider them an accept-invalid
> bug :o).

Well, they are also used in druntime, in core.stdc.math

BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it.
Practically everything in there has a better implementation in std.math.

On 03-05-2012 17:13, Don Clugston wrote:
> On 03/05/12 16:13, Andrei Alexandrescu wrote:
>> On 5/3/12 9:55 AM, Don Clugston wrote:
>>> On 28/04/12 20:47, Walter Bright wrote:
>>>> Andrei and I had a fun discussion last night about this question. The
>>>> idea was which features in D are redundant and/or do not add
>>>> significant
>>>> value?
>>>>
>>>> A couple already agreed upon ones are typedef and the cfloat, cdouble
>>>> and creal types.
>>>>
>>>> What's your list?
>>>
>>> Other ones which were agreed to a long time ago were:
>>>
>>> * NCEG operators
>>>
>>> * built-in .sort and .reverse
>>
>> Good ones. In fact I even discounted them from this discussion because
>> I'd already considered them gone. Walter agreed that I don't mention
>> them in TDPL, with the intent to have them peter out.
>>
>> One good step right now would be to remove NCEG operators from the
>> online documentation. Later on, we'll consider them an accept-invalid
>> bug :o).
>
> Well, they are also used in druntime, in core.stdc.math
>
> BTW I *hate* that module, I don't know why it exists. Even worse, it
> seems to be growing -- people are adding more things to it.
> Practically everything in there has a better implementation in std.math.

But not quite everything yet. When I tried to pure/nothrow/@safe-ify std.math[special], I eventually stumbled upon code that used core.stdc.math.

It would definitely be nice if we could completely kill any dependency on that module, so we can actually make proper use of pure/nothrow/@safe, etc.

-- 
- Alex

On May 3, 2012, at 8:13 AM, Don Clugston wrote:

> On 03/05/12 16:13, Andrei Alexandrescu wrote:
>> 
>> 
>> Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out.
>> 
>> One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o).
> 
> Well, they are also used in druntime, in core.stdc.math
> 
> BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it.
> Practically everything in there has a better implementation in std.math.

core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface.  It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro.  If there is anything nonstandard in there, I'm not aware of it.