Does D have too many features?

foobar foo at bar.com
Tue May 1 14:03:33 PDT 2012


On Tuesday, 1 May 2012 at 17:50:38 UTC, Alex Rønne Petersen
wrote:
> On 01-05-2012 19:09, Jonathan M Davis wrote:
>> On Tuesday, May 01, 2012 16:31:25 Alex Rønne Petersen wrote:
>>> 1) So because some people might use a feature incorrectly due 
>>> to lack of
>>> knowledge in algorithms and data structures, we should 
>>> cripple the language?
>>
>> If in is not restricted to a particular level Big-O 
>> complexity, then you
>> cannot safely use it in generic code. That's why all of the 
>> functions in
>> std.container give their Big-O complexity.
>
> I don't think 'in' is actually used in any generic code (other 
> than code specifically written for AAs, in which it *does* have 
> a specific complexity in any case).
>
> I know I wouldn't use 'in' in truly generic code in any case, 
> exactly because it has no defined complexity (even today; it's 
> overloadable just like most other binary operators).
>
>>
>> In C++ [] is supposed to be O(log n) at worst. I would expect 
>> it to be the
>> same in D, and since in is doing essentially the same 
>> operation, I would
>> expect it to have the same Big-O complexity.
>
> This is a good point, but not one I would subscribe to; it only 
> holds true if you consider 'in' to be an operation purely 
> limited to AAs. But this is already not the case given that it 
> can be overloaded. So, I don't think that it having different 
> complexity for arrays is a big deal.
>
> Personally, I consider 'in' to be syntax sugar for the language 
> user. To me, it does not seem like a feature that a library of 
> generic algorithms should be using at all.
>
>>
>> No, nothing is stopping a programmer from giving it horrible 
>> complexity, but
>> the standard library and language should _definitely_ stick to 
>> O(log n) worst
>> case for in and []. It would be a disaster for generic 
>> algorithms if in worked
>> on normal arrays, because it would not be possible to maintain 
>> the required
>> Big-O complexity.
>
> I agree that any overload of [] and 'in' that Phobos does 
> should stick to that constraint when possible (I say when 
> possible, because sometimes innovative uses of these operators 
> can't stick to this rather strict and mundane constraint; 
> consider for example interaction with a database or what do I 
> know...).
>
> But again, I don't think 'in' is something a generic algorithm 
> should be using. We have the functions in std.algorithm and 
> std.container if we need to write generic code.
>
> Also, I don't think language design should be *too* biased by 
> the standard library's preferences. Not everyone agrees with 
> Phobos conventions and we have to respect that IMHO. Just 
> because it's a standard library doesn't mean that it should 
> dictate users of the language who don't use the standard 
> library.
>
>>
>> - Jonathan M Davis

vote++

I like your POV that operators are useful shortcuts (syntax
sugar) meant for the end user whereas library authors should use
the full function names for generic code. IIRC C++'s STL does the
same - for instance the map::operator[] is a simple wrapper
around map's functions.

Is this included in D's style guide?


More information about the Digitalmars-d mailing list