May 12, 2012
On 05/12/2012 01:47 AM, Ali Çehreli wrote:
> On 05/11/2012 02:45 PM, Timon Gehr wrote:
>> On 05/11/2012 10:10 PM, Nick Sabalausky wrote:
>>> 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; }
>
> Isn't that an inconsistency in the language then? Are pointer values
> implicitly convertible to bool or not?
>
> Ali

if(condition) { ... }

is equivalent to

if(cast(bool)condition) { ... }

i.e. this conversion is 'explicit'.
May 12, 2012
On Saturday, 12 May 2012 at 00:00:20 UTC, Timon Gehr wrote:
> > the horrible compilation times,
>
> wat? The so-fast-I-could-not-grab-a-coffee-during-compilation kind of horrible? Otherwise he might have hit a bug there.


My work project takes about 8 seconds to compile and link
in my normal build if there's RAM available, and can be much
longer if there isn't.

Since the compile takes upwards of 512 MB peak, having enough
memory for the fast build doesn't happen many times.


The build also takes well over a full minute if I use -O.


The emulator might be using -O and getting brutally slow,
or being run on a box without a billion terabytes of RAM.



...or perhaps I just think ~10 second build times are slow
because I've been spoiled by all the other D I do. lol
May 12, 2012
> Yes, "in" for statically-sized arrays does make sense because the complexity if bound at compilation time.
>
> Andrei

But complexity is not the only problem with the proposed
operator in for arrays. That operator does not represent the
same operation as operator in for associative arrays. Looking
up an element based on its key is different from looking it up
based on its value. The following  would be true for the
proposed operator in for arrays:

!(a in b) || *(a in b) == a

And the following is true for operator in for associative
arrays:

!(a in b) || *(a in b) == b[a]

The same operator should not be used for fundamentally
different operations. I don't think using operator in to look
up array elements based on their value is any better than
using left shift operator to write to streams or using plus
to concatenate strings. If operator in worked on arrays, it
should actually take an index as the left operand and return a
pointer to the element at that index if the index was less than
array length and null otherwise. But that wouldn't be very
useful.
May 12, 2012
On 5/11/12 9:55 PM, jerro wrote:
>> Yes, "in" for statically-sized arrays does make sense because the
>> complexity if bound at compilation time.
>>
>> Andrei
>
> But complexity is not the only problem with the proposed
> operator in for arrays. That operator does not represent the
> same operation as operator in for associative arrays.

That's a good argument, but then you may think of the array as a small set, which would have the same semantics.

Andrei

May 12, 2012
On 5/12/12 1:18 AM, Andrei Alexandrescu wrote:
> On 5/11/12 1:10 PM, Mehrdad wrote:
>> On Friday, 11 May 2012 at 18:05:58 UTC, Mehrdad wrote:
>>> and the solution indeed was NOT something I would've found by myself
>>> without spending hours on it.
>>
>>
>> Just a note: I believe I *had* seen SortedRange in the docs, but I'd
>> never realized there's something called assumeSorted() that I was
>> supposed to call... so I was searching up and down for how to search an
>> *arbitrary* container, not how to search something which was already
>> pre-sorted for me.
>> (In retrospect, I probably should've just coded binary search myself...)
>> It's very counterintuitive to have to make a new object (or struct) just
>> to do binary search on an array...
>
> At the same time it clarifies, documents, and statistically verifies
> that you pass a sorted range. Also, D's binary search works with
> non-array ranges, but C#'s works only with arrays (which it assumes
> sorted only by convention).
>
> I think we copiously made the right call there.
>
>
> Andrei

Add a binarySearch(range, object) method that does all of that?

I mean, I don't want to write more than a single line of code to do a binarySearch...
May 12, 2012
On 5/12/12 3:40 AM, 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?

Ruby has any?:

http://ruby-doc.org/core-1.9.3/Enumerable.html#method-i-any-3F

And it's the best of the two worlds: given a block (a lambda) it works like D. Give no lambda and it just returns true if the enumerable has any elements.

Ruby wins again. :-P
May 12, 2012
On 5/12/12 3:24 AM, Walter Bright wrote:
>     x + 3 = 5
>
> on the board and asked people to "solve for x", they would fail
> completely. But, if she wrote:
>
>     ( ) + 3 = 5
>
> and asked them to "fill in the circle with the number that makes it
> work", they all went "of course, it's 2!"

When I read "solve *for* x" I don't understand it. What do you mean "for x"? Like doing a favor to x?

In Spanish we say "hallar el valor de x" which means "find the value of x"...

I'm not a native English speaker so I don't know if "solve for x" sounds natural if you haven't done ecuations before... but for me it doesn't. :-P
May 12, 2012
On 5/11/2012 8:51 PM, Ary Manzana wrote:
> On 5/12/12 3:24 AM, Walter Bright wrote:
>> x + 3 = 5
>>
>> on the board and asked people to "solve for x", they would fail
>> completely. But, if she wrote:
>>
>> ( ) + 3 = 5
>>
>> and asked them to "fill in the circle with the number that makes it
>> work", they all went "of course, it's 2!"
>
> When I read "solve *for* x" I don't understand it. What do you mean "for x"?
> Like doing a favor to x?
>
> In Spanish we say "hallar el valor de x" which means "find the value of x"...
>
> I'm not a native English speaker so I don't know if "solve for x" sounds natural
> if you haven't done ecuations before... but for me it doesn't. :-P

It's normal English mathematical jargon.
May 12, 2012
On 5/11/2012 3:25 PM, SomeDude wrote:
> I believe it takes no less than a year of full time programming
> to become a proficient C++ programmer (by proficient, I mean a
> programmer who doesn't fall in all the traps that the language
> offers, and therefore spends more time coding than debugging).

Eh, I'd put it much longer than that. Or maybe I just have a different view of proficient!
May 12, 2012
"Mehrdad" <wfunction@hotmail.com> wrote in message news:hnottedhszpplpbqtvyx@forum.dlang.org...
> On Friday, 11 May 2012 at 23:47:18 UTC, Walter Bright wrote:
>>
>> I tend to agree. I think this is better (I've never gotten around to implementing it):
>>
>>   enum hasMember(T, string name) = __traits(hasMember, T, name);
>>
>> I.e. analogously to struct templates.
>
> Mmmm... I like the idea/syntax, but not the word "enum". It certainly has nothing to do with enums, so I think it'd be even more confusing in that regard. :)

While do I agree 100% that 'enum' is a horrid name (*much* worse than calling immutables "invariant" - that at least had *some* logic to it), that is a completely separate issue.