On 11-05-2012 23:41, SomeDude wrote:
> On Friday, 11 May 2012 at 20:35:53 UTC, Alex Rønne Petersen wrote:
>>> Except that it would break the generally expected algoritmic
>>> complexity of in,
>>> so it'll never happen ( O(n) for arrays, whereas the worst case that
>>> would be
>>> acceptable would be O(lg n) - e.g. what a binary tree could achieve).
>>>
>>> - Jonathan M Davis
>>
>> 'in' isn't useful in generic code. How it's defined (return type and
>> parameter type) depends entirely on the type being operated on (who
>> says it's an AA? Or a map-like type at all?), so it cannot be used
>> generically in any sensible way.
>>
>> As such, maintaining any specific algorithmic complexity for it serves
>> no purpose IMHO.
>
> I think this has been discussed several times already, and you still
> haven't convinced any of us.

Then you probably didn't read the replies to the other (sub-)thread about it.

-- 
- Alex

On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
> "Mehrdad"<wfunction@hotmail.com>  wrote in message
> news:oksltzwvkdrrjidcnqnm@forum.dlang.org...
>> On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:
>>> On 11-05-2012 20:05, Mehrdad wrote:
>>>> 6. The 'in' operator returns a pointer (instead of a boolean). Which is
>>>> fine, except that it's not what you'd expect in any languages other than
>>>> C/C++. i.e. Non-intuitive
>>> I've always found it very intuitive actually... and it saves me from
>>> having to write extra code to do the actual lookup (speed isn't even the
>>> point here, I just want concise code).
>>
>> Yes, I agree, but consider that D users should NOT have to work with
>> pointers to do something so basic, like testing to see if something is in
>> an associative array!
>>
>> The mere fact that it uses a pointer makes it unintuitive to a large
>> number of people coming from C#/Java/Python/etc.
>>
>
> I use 'in' all the time, and I never even think about it returning a
> pointer. I just do:
>
> if(foo in bar)
>
> And it just works. So I don't see a particularly big problem here.
>
>

Try this:

bool fun(){ return foo in bar; }

"Steven Schveighoffer" <schveiguy@yahoo.com> wrote in message
news:op.wd5o86s3eav7ka@steves-laptop...
On Fri, 11 May 2012 13:47:05 -0400, Alex Rønne Petersen
<xtzgzorex@gmail.com> wrote:
>>
>> Complicated language structure? Long compilation times?
>
>I can attest that on certain types of projects (i.e. template heavy), D's lightning fast compilation time goes out the window.  It has improved greatly, but there are still some improvements that can be made.
>
>For instance, dcollections, which is about 10kloc takes 17 seconds to compile all the unit tests.  It used to be well over a minute, till walter changed a linear lookup to a hash lookup on the symbol table.  There's an outstanding issue which is similar still in bugzilla:

Meh, that's still nothing compared to C++. The sample games included with Marmalade and the Marm-based IwGame engine take *serveral* minutes to compile - and those are just sample programs!

Template-heavy projects don't throw D's lightning fast compilation times out the window, it just makes them less lightning-like. It's still an order of magnature faster than equivalent, or even merely similar, C++.

On Friday, 11 May 2012 at 21:40:44 UTC, Andrei Alexandrescu wrote:
> Totally agreed. Intuition is supported by having seen the same or a similar pattern before. In this case D takes an unusual approach, which I think is better than the established approach.
>
> I have added a reference (https://github.com/andralex/phobos/commit/650609be9b4146db3526b50ccfca6776fed73b51) such that searching the page std.algorithm for "binary search" will lead to the correct reference.
>
>
> Andrei

Awesome!

On Friday, May 11, 2012 22:40:08 Mehrdad wrote:
> On Friday, 11 May 2012 at 20:20:36 UTC, Jonathan M Davis wrote:
> > That's definitely an example of something that depends on your background. std.algorithm.any does _exactly_ what it would do in a functional language.
> 
> Well, I know some FP (Scheme/newLISP) but they don't have an
> "any" function. I don't know about F#, but my guess would be that
> it would do the same thing as C# would (for obvious reasons).
> 
> Are you thinking of a language in particular that has D's behavior? Or is this just a guess?

I know that haskell has such a function, and there were a number of complaints previously that we _didn't_ have an any function which does exactly what std.algorithm.any now does. It's a very functional approach to use predicates like that and I get the impression that it's common in other functional languages based on other's comments. The only one off the top of my head that I _know_ has such a function though is haskell.

- Jonathan M Davis

On Friday, May 11, 2012 20:38:41 Mehrdad wrote:
> On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:
> > Templates are stencils for generating code. There's nothing confusing about that.
> 
> "Stencils for generating code"? _This_??! :O
> 
> template hasMember(T, string name)
> { enum hasMember = __traits(hasMember, T, name); }
> 
> 
> Imagine a new user's confusion when seeing something like this. (Not sure I got it exactly right, but my point is there.)

Templates are a code-generation tool. They're "templates" for code. I really think that the majority of programmers don't quite get that, even when they've programmed in C++ quite a bit. Templates are frequently used for stuff like making it so that you can construct a container with a different element type than another container of the same type or letting functions take a variety of argument types. Actually actively trying to _generate_ code with them is getting into template metaprogramming land, which is very ugly in C++ and therefore very foreign to many (most?) programmers. D makes it _much_ easier and _much_ more sane, so we end up doing it all the time, and it's definitely something that many programmers coming to D are going to have to learn as opposed to it being completely intuitive. Much of it really isn't all that complicated or difficult IMHO, but it's definitely new and different for many programmers.

- Jonathan M Davis

> What started out as C with classes started acquiring this feature and
> that feature until the whole thing is just a haphazard heap of
> misfitting self-contradictory pieces, which requires an enormous amount
> of essentially-arbitrary rules just to clarify something as simple as,
> for example, automatic type conversions.

Partially, this also can be told about D, too. It started as a cleaner C++ (I think) and grew up a bit complicated.

Before arguing the contrary, please remember that C++ looks not complicated to Stroustrup.

Maybe simply addressing the most bitter drawbacks and inconsistencies of C++ (and when I say that, I say notably syntax stupidities, *then* conceptual stupidities) was enough for, let's say, D_v1. Then, more, for D_v2. Maybe trying to address too much at once?

My feeling (I tried to port and work something in D) is that it is a good language. But a complicate one and the learning time tends to be limited today.

C caught in the first place for its simplicity. Java, too ("hey, no pointers!"). Annotations and other hell were added later, *after* the naguage got assimilated. C# too ("hey! C++ made *simpler*!"). Then it was C#2, 3, 4 etc. True, C++ grew up a complicated beast, but *gradually*. At the beginning, it was not.

D does not have that gradualism in growing complicated. Not for its developers, but for its (mass) users.

On Friday, May 11, 2012 23:45:30 Timon Gehr wrote:
> On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
> > "Mehrdad"<wfunction@hotmail.com> wrote in message news:oksltzwvkdrrjidcnqnm@forum.dlang.org...
> > 
> >> On Friday, 11 May 2012 at 18:16:02 UTC, Alex Rønne Petersen wrote:
> >>> On 11-05-2012 20:05, Mehrdad wrote:
> >>>> 6. The 'in' operator returns a pointer (instead of a boolean). Which is
> >>>> fine, except that it's not what you'd expect in any languages other
> >>>> than
> >>>> C/C++. i.e. Non-intuitive
> >>> 
> >>> I've always found it very intuitive actually... and it saves me from having to write extra code to do the actual lookup (speed isn't even the point here, I just want concise code).
> >> 
> >> Yes, I agree, but consider that D users should NOT have to work with pointers to do something so basic, like testing to see if something is in an associative array!
> >> 
> >> The mere fact that it uses a pointer makes it unintuitive to a large number of people coming from C#/Java/Python/etc.
> > 
> > I use 'in' all the time, and I never even think about it returning a pointer. I just do:
> > 
> > if(foo in bar)
> > 
> > And it just works. So I don't see a particularly big problem here.
> 
> Try this:
> 
> bool fun(){ return foo in bar; }

Then you do

bool fun() { return cast(bool)(foo in bar); }

It's not a big deal at all. It's just that if you expect in to return bool rather than a pointer, you're going to be surprised at what happens when you write a function like that rather than use it in an if condition. But since the documentation clearly states that it returns a pointer, it shouldn't really surprise anyone - unless they failed to read either the documentation or TDPL and go completely off of what they _think_ the code should mean without actually reading anything which would teach them the language (which is a bad idea anyway).

- Jonathan M Davis

On Friday, 11 May 2012 at 19:02:53 UTC, Mehrdad wrote:
> On Friday, 11 May 2012 at 18:53:57 UTC, H. S. Teoh wrote:
>> On Fri, May 11, 2012 at 08:38:41PM +0200, Mehrdad wrote:
>>> On Friday, 11 May 2012 at 18:21:24 UTC, H. S. Teoh wrote:
>>> >Templates are stencils for generating code. There's nothing
>>> >confusing about that.
>>> 
>>> 
>>> "Stencils for generating code"? _This_??! :O
>>> 
>>>  template hasMember(T, string name)
>>>  { enum hasMember = __traits(hasMember, T, name); }
>>> 
>>> 
>>> Imagine a new user's confusion when seeing something like this.
>>> (Not sure I got it exactly right, but my point is there.)
>>
>> Yes, that's exactly how stencils work. You're essentially generating a declaration of the form:
>>
>> 	enum hasMember = ...;
>>
>> <snip>
>
>
> That's not how you see it when you're learning though.
>
> It's more like, I can imagine someone asking these:
>
> 1. Why the heck do I see "hasMember" twice?
> 2. What does this have to do with enums?
> 3. Where is anything getting "returned"???
> 4. So you mean templates are THINGS?? I thought you needed a template SOMETHING, like a template struct, template function, etc...
> 5. What the heck is TypeTuple!()? Where's the blueprint?
>
>
> etc.

BTW, don't forget to have a look at the articles on the left:
http://dlang.org/tuple.html

On Friday, 11 May 2012 at 21:58:02 UTC, Jonathan M Davis wrote:
> Then you do
>
> bool fun() { return cast(bool)(foo in bar); }
>

cast() scares the **** out of me