"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jthr4a$3f3$1@digitalmars.com...
>
> I swear I'd just call it "range".
>
> Andrei
>

Sure, why not.  http://d.puremagic.com/issues/show_bug.cgi?id=8371

>
> Given:
>
> @property int delegate() foo(){ ... }
> @property int bar(){ ... }
> int baz(){ ... }
>
> foo(); // calls the delegate.
> bar(); // illegal
> baz;   // ok, call baz
>
> dmd -property gets every single one of these wrong. -property does _not_
> enforce @property semantics. It only adds a silly rule that was never
> part of the @property design. I am astonished that it made it into the
> compiler.

+1

On Tuesday, July 10, 2012 22:04:17 Timon Gehr wrote:
> @property int delegate() foo(){ ... }
> @property int bar(){ ... }
> int baz(){ ... }
> 
> foo(); // calls the delegate.
> bar(); // illegal
> baz; // ok, call baz
> 
> dmd -property gets every single one of these wrong. -property does _not_ enforce @property semantics.

The current implementation of -property is horribly broken:

http://d.puremagic.com/issues/show_bug.cgi?id=4183 http://d.puremagic.com/issues/show_bug.cgi?id=8162

It's not actually enforcing what it's supposed to enforce, and it needs to be fixed.

- Jonathan M Davis

On Tuesday, July 10, 2012 21:07:51 Jacob Carlborg wrote:
> Second, it would be much easier if it would be possible to better name these ranges, something like interfaces but without polymorphism. This as been mentioned several times before.

They're templated types. They have to be templated types. And since they're templated types, better names do you no good whatsoever as far as declaring a variable goes. You'll _never_ be able to do something like

NiceName range;

NiceName will always be templated. The _closest_ that you get is with Voldemort types. Since they're templated as part of the function that they're in rather than separately, they end up with names such as Result or FilteredRange, but you couldn't do

FilteredRange range;

because that type depends on its outer scope (in this case, filter). You'd _still_ have to use typeof or ReturnType if you need to declare such a variable without directly assigning it (in which case, you can use auto). And if you have a separate range type rather than a Voldemort Type, you end up with stuff like Until!("a == b", string, dchar). The templated nature of ranges makes it impossible to have friendly names which you can use to simply declare variables of a particular range type. auto, ReturnType, and typeof are required tools for dealing with templated types like this.

- Jonathan M Davis

Jacob Carlborg , dans le message (digitalmars.D:171725), a écrit :
>> To make the best implementation would require to know how the String context works.
>>
> String is a wrapper around str.array.Appender.

Then, if the purpose is to make the code efficient, I would use the loop and append everything to the result without creating the params array, and even without creating the string p. Appender is made to append everything directly to it efficiently.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.249.1341951069.31962.digitalmars-d@puremagic.com...
> On Tuesday, July 10, 2012 21:07:51 Jacob Carlborg wrote:
>> Second, it would be much easier if it would be possible to better name these ranges, something like interfaces but without polymorphism. This as been mentioned several times before.
>
> They're templated types. They have to be templated types. And since
> they're
> templated types, better names do you no good whatsoever as far as
> declaring a
> variable goes. You'll _never_ be able to do something like
>
> NiceName range;
>

This isn't really true.  You can still in some cases  the type relative to
some other type. (warning: old code, may not compile any more)
Sure, you can use auto and typeof, but that doesn't make it clearer.

struct SubSequences(R)
{
    R r;
    R s;
    Take!R c;
    int n;
    this(R r)
    {
        this.r = r;
        s = r;
        n = 0;
        c = take(r, 1);
        popFront();
    }
    void popFront()
    {
        c.popFront();
        if (c.empty)
        {
            c = take(r, ++n);
            s.popFront();
        }
    }
    Take!R front() { return c; }
    bool empty() { return s.empty; }
    typeof(this) save() { return this; }
};
SubSequences!R subSequences(R)(R r) { return SubSequences!R(r); }

Jacob Carlborg , dans le message (digitalmars.D:171769), a écrit :
> On 2012-07-10 20:04, Andrei Alexandrescu wrote:
> 
>> Then store an array. "No one's put a gun to yer head." http://youtu.be/CB1Pij54gTw?t=2m29s
> 
> That's what I'm doing.
> 

And that's what you should do. Algorithm are not made to be stored in struct or class instance. You could use InputRange(E) and friends to do that, but that's often not optimal. Algorithm are here to do their job and output non-lazy result in the end.

On 11-Jul-12 00:07, Tobias Pankrath wrote:
>>
>> Given:
>>
>> @property int delegate() foo(){ ... }
>> @property int bar(){ ... }
>> int baz(){ ... }
>>
>> foo(); // calls the delegate.
>> bar(); // illegal
>> baz;   // ok, call baz
>>
>> dmd -property gets every single one of these wrong. -property does _not_
>> enforce @property semantics. It only adds a silly rule that was never
>> part of the @property design. I am astonished that it made it into the
>> compiler.
>
> +1

Same here. Still no idea what they were smoking at the time.

-- 
Dmitry Olshansky

On 2012-07-10 22:13, Christophe Travert wrote:

> Then, if the purpose is to make the code efficient, I would use the loop
> and append everything to the result without creating the params array,
> and even without creating the string p. Appender is made to append
> everything directly to it efficiently.

Yeah, I've been thinking about doing that more.

-- 
/Jacob Carlborg

On 07/10/2012 10:48 AM, Simen Kjaeraas wrote:
> On Tue, 10 Jul 2012 16:15:09 +0200, Jacob Carlborg <doob@me.com> wrote:

>> How do you store your ranges in a struct or class? Most of them are
>> voldemort types.
>
> Well, there is std.range.inputRangeObject, but as the name indicates

As the name "misleads"... :)

>, it's
> only an input range.

... it can be used as any one of the non-OutputRanges:

import std.algorithm;
import std.range;
import std.stdio;

void main() {
     int[] a1 = [1, 2, 3];

     ForwardRange!int r1 = inputRangeObject(map!"2 * a"(a1));
     ForwardRange!int r2 = inputRangeObject(map!"a ^^ 2"(a1));

     auto a2 = [r1, r2];

     writeln(a2);
}

Replace ForwardRange!int above with any other non-OutputRange, and as long as the input to inputRangeObject() is compatible, it will work. (static if magic).

Ali