Henning Pohl , dans le message (digitalmars.D:174569), a écrit :
On Friday, 10 August 2012 at 14:10:38 UTC, Vladimir Panteleev
wrote:
On Friday, 10 August 2012 at 14:10:02 UTC, Vladimir Panteleev
wrote:
On Friday, 10 August 2012 at 14:05:16 UTC, Henning Pohl wrote:
Oups, sorry, imagine
Henning Pohl , dans le message (digitalmars.D:174572), a écrit :
That is what I was trying first, but I could not make it work.
Maybe you can show me how it's done?
For example:
import std.stdio;
template TupleToArray(T...)
{
static if (T.length == 1)
{
enum TupleToArray = [T[0]];
If a has is a range, it's an output range, because it's something you
fee data to. Output range have only one method: put. Johannes used this
method. But it's not sufficient, you need something to start and to
finish the hash.
To bring consistency in the library, we should not remove this
I'm not familiar with hash functions in general.
I think the core of std.hash is the digest function:
digestType!Hash digest(Hash)(scope const(void[])[] data...)
if(isDigest!Hash)
{
Hash hash;
hash.start();
foreach(datum; data)
hash.put(cast(const(ubyte[]))datum);
return
Regan Heath , dans le message (digitalmars.D:174462), a écrit :
Message-Digest Algorithm is the proper term, hash is another, correct,
more general term.
hash has other meanings, Message-Digest Algorithm does not.
I think the question is: is std.hash going to contain only
message-digest
Chris Cain , dans le message (digitalmars.D:174466), a écrit :
On Wednesday, 8 August 2012 at 13:38:26 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
I think the question is: is std.hash going to contain only
message-digest algorithm, or could it also contain other hash
Chris Cain , dans le message (digitalmars.D:174477), a écrit :
I think you misunderstood me (and it's probably my fault, since I don't
know much of hash functions), I was wanted to compare two kind of
concepts:
1/ message digest functions, like md5, or sha1, used on large files,
which is what
Johannes Pfau , dans le message (digitalmars.D:174478), a écrit :
but I don't know how make it an overload. See thread overloading a
function taking a void[][] in D.learn for details.
Don't overload the function taking a void[][]. Remplace it. void[][] is
a range of void[].
Timon Gehr , dans le message (digitalmars.D:174361), a écrit :
On 08/06/2012 09:42 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater
Walter Bright , dans le message (digitalmars.D:174360), a écrit :
On 8/6/2012 12:00 PM, Philippe Sigaud wrote:
Yes, well we don't have a condition system. And using exceptions
during lexing would most probably kill its efficiency.
Errors in lexing are not uncommon. The usual D idiom of having
Walter Bright , dans le message (digitalmars.D:174393), a écrit :
If the delegate returns, then the lexer recovers.
That's an option, if there is only one way to recover (which is a
reasonable assumption).
You wanted the delegate to decide what to do with the errors (ignore,
throw exception,
Walter Bright , dans le message (digitalmars.D:174394), a écrit :
On 8/7/2012 1:14 AM, Jonathan M Davis wrote:
But you can also configure the lexer to return an error token instead of
using
the delegate if that's what you prefer. But Walter is right in that if you
have to check every token
Jacob Carlborg , dans le message (digitalmars.D:174421), a écrit :
On 2012-08-07 12:06, Jonathan M Davis wrote:
It's easier to see where in the range of tokens the errors occur. A delegate
is disconnected from the point where the range is being consumed, whereas if
tokens are used for
Tommi , dans le message (digitalmars.D:174314), a écrit :
In D it's not possible to make opCast operators implicit.
Therefore I see no way of making transparent wrappers; like
structs which could be used as a drop-in replacement for plain
old data types.
E.g if I wanted to make a SafeInt
Jonathan M Davis , dans le message (digitalmars.D:174310), a écrit :
IMO, the behavior should be this: when trying to call the template with
a argument that is an enum type based on string, the compiler should try
to instanciate the template for this enum type, and isSomeString should
fail.
deadalnix:
The same way, the difference between a delegate and an expression don't
exist anymore.
int fun();
int fun(int t);
One solution would be to find a way that would enable fun to be both a
function and its return type, and that would enable 1.fun to be both
delegate and its return
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
What exactly do you consider byzantine here
Andrej Mitrovic , dans le message (digitalmars.D:174259), a écrit :
On 8/4/12, Jonathan M Davis jmdavisp...@gmx.com wrote:
snip
I agree with you. isSomeString!T predicate failing maybe isn't as
serious as !isSomeString!T passing and ending up with wrong results.
At the very least this
Jonathan M Davis , dans le message (digitalmars.D:174267), a écrit :
On Saturday, August 04, 2012 15:22:34 Jonathan M Davis wrote:
On Sunday, August 05, 2012 00:15:02 Timon Gehr wrote:
T fun(T)(T arg) if(isSomeString!arg){
return arg~arg[0];
}
IMO, the behavior should be this:
Jonathan M Davis , dans le message (digitalmars.D:174191), a écrit :
On Thursday, August 02, 2012 11:08:23 Walter Bright wrote:
The tokens are not kept, correct. But the identifier strings, and the string
literals, are kept, and if they are slices into the input buffer, then
everything I said
Era Scarecrow , dans le message (digitalmars.D:174206), a écrit :
I would think it does however during verbose output specifying
if an invariant or contract is changing data and that may alter
behavior.
Signatures in some place should be by default const, pure, nothrow. This
is the case
Dmitry Olshansky , dans le message (digitalmars.D:174214), a écrit :
Most likely - since you re-read the same memory twice to do it.
You're probably right, but if you do this right after the token is
generated, the memory should still be near the processor. And the
operation on the first read
Jonathan M Davis , dans le message (digitalmars.D:174223), a écrit :
On Saturday, August 04, 2012 15:32:22 Dmitry Olshansky wrote:
I see it as a compile-time policy, that will fit nicely and solve both
issues. Just provide a templates with a few hooks, and add a Noop policy
that does nothing.
Jacob Carlborg , dans le message (digitalmars.D:174131), a écrit :
static if(isNarrowString!R)
Unqual!(ElementEncodingType!R) first = range[0];
else
dchar first = range.front;
I find it more comfortable to just use
first = range.front, with a range of char or ubyte.
This range does
deadalnix , dans le message (digitalmars.D:174155), a écrit :
The tokens are not kept, correct. But the identifier strings, and the
string literals, are kept, and if they are slices into the input buffer,
then everything I said applies.
Ok, what do you think of that :
lexer can have a
Jonathan M Davis , dans le message (digitalmars.D:173942), a écrit :
It may very well be a good idea to templatize Token on range type. It would
be
nice not to have to templatize it, but that may be the best route to go. The
main question is whether str is _always_ a slice (or the result of
Walter Bright , dans le message (digitalmars.D:174015), a écrit :
On 8/2/2012 12:49 AM, Jacob Carlborg wrote:
But what I still don't understand is how a UTF-8 range is going to be usable
by
other range based functions in Phobos.
Worst case use an adapter range.
Yes
auto r =
Jonathan M Davis , dans le message (digitalmars.D:174059), a écrit :
In either case, because the consumer must do something other than simply
operate on front, popFront, empty, etc., you're _not_ dealing with the range
API but rather working around it.
In some case a range of dchar is
Andrei Alexandrescu , dans le message (digitalmars.D:174060), a écrit :
I agree frontUnit and popFrontUnit are more generic because they allow
other ranges to define them.
Any range of dchar could have a representation (or you may want to call
it something else) that returns a range of char
Jacob Carlborg , dans le message (digitalmars.D:174069), a écrit :
On 2012-08-02 10:15, Walter Bright wrote:
Worst case use an adapter range.
And that is better than a plain string?
because its front method does not do any decoding.
Jonathan M Davis , dans le message (digitalmars.D:173860), a écrit :
struct Token
{
TokenType type;
string str;
LiteralValue value;
SourcePos pos;
}
struct SourcePos
{
size_t line;
size_t col;
size_t tabWidth = 8;
}
The occurence of tabWidth surprises me.
What is col
bearophile , dans le message (digitalmars.D:173647), a écrit :
Turning that in D code that uses opApply is not hard, but the
code inflates 3X, and you can't use most std.algorithm on it.
I believe most std.algorithm that work on input range could be made to
work with opApply, or opApply-like
Christophe Travert, dans le message (digitalmars.D:173787), a écrit :
bearophile , dans le message (digitalmars.D:173647), a écrit :
Turning that in D code that uses opApply is not hard, but the
code inflates 3X, and you can't use most std.algorithm on it.
I believe most std.algorithm
Jonathan M Davis , dans le message (digitalmars.D:173382), a écrit :
scope on local variables is going away for pretty much the same reason that
delete is. They're unsafe, and the fact that they're in the core language
encourages their use. So, they're being removed and put into the standard
bearophile , dans le message (digitalmars.D:173297), a écrit :
I'm not sure what you mean. Do you mean I can go edit the open
source compiler and add in my own language feature? Or does the
ability to add a $/@ operator already exist?
I mean that D compiler writers don't need to introduce
Russel Winder , dans le message (digitalmars.D:173102), a écrit :
--=-aHxuwwF1pyt7fCGYFQXP
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, 2012-07-24 at 13:56 -0400, Andrei Alexandrescu wrote:
[=E2=80=A6]
The example is:
=20
int[] arr1 =3D [
Don Clugston , dans le message (digitalmars.D:173192), a écrit :
The question really is, do postfix ++ and -- make sense for reference
types? Arguably not. From a theoretical sense, the existing behaviour
does make sense, but in practice, every time it is used, it is probably
a bug.
The
Joseph Rushton Wakeling , dans le message (digitalmars.D:172997), a
écrit :
In other words, either your input range needs hasLength!R == true or
you need to manually specify the total number of items when calling
randomSample:
But what if the total number of items is not known in advance?
monarch_dodra , dans le message (digitalmars.D:173005), a écrit :
Maybe I should put this request elsewhere? I'm not sure if there
is a place where I should put this?
I know this is not a very exciting issue, but I think it is a
very important to resolve, preferably sooner than later.
monarch_dodra , dans le message (digitalmars.D:172700), a écrit :
I think it would be better to initialize on copy, rather than
default initialize. There are too many cases an empty array is
created, then initialized on the next line, or passed to
something else that does the initialization
monarch_dodra , dans le message (digitalmars.D:172710), a écrit :
One of the reason the implementation doesn't let you escape a
reference is that that reference may become (_unverifiably_)
invalid.
The same applies to a dynamic array: it is undistinguishable from a
sliced static array. More
q66 , dans le message (digitalmars.D:172716), a écrit :
(so instead of calling a(b(c(d(e(f) you can just call
a.b.c.d.e.f())
rather f.e.d.c.b.a, if you omit the empty parenthesis after each letter
(but f).
Petr Janda , dans le message (digitalmars.D:172719), a écrit :
Array gets sorted, then doubles are removed (uniq) and then
everything is converted to a string (map).
Everything was recently introduced around 2.059.
Ok, but what is map!(). What's the point of the exclamation mark,
is it a
Robik , dans le message (digitalmars.D:172718), a écrit :
On Thursday, 19 July 2012 at 14:21:47 UTC, Petr Janda wrote:
Hi,
Hi
I'm an occasional lurker on the D forums just to see where the
language is going,but I'm a little puzzled. In another thread I
found this code
auto r = [5, 3,
Petr Janda , dans le message (digitalmars.D:172727), a écrit :
On Thursday, 19 July 2012 at 14:31:53 UTC,
trav...@phare.normalesup.org (Christophe Travert) wrote:
q66 , dans le message (digitalmars.D:172716), a écrit :
(so instead of calling a(b(c(d(e(f) you can just call
a.b.c.d.e.f
Alex Rønne Petersen , dans le message (digitalmars.D:172728), a écrit :
On 19-07-2012 16:36, Christophe Travert wrote:
Petr Janda , dans le message (digitalmars.D:172719), a écrit :
Array gets sorted, then doubles are removed (uniq) and then
everything is converted to a string (map
Matthias Walter , dans le message (digitalmars.D:172673), a écrit :
I looked at Bug #6153 (Array!(Array!int) failure) and found that the
This exactly is what makes the following code fail:
Array!(Array!int) array2d;
array2d.length = 1;
array2d[0].insert(1);
The inner array array2d[0]
I see you found the appropriate entry to discuss this bug:
http://d.puremagic.com/issues/show_bug.cgi?id=6153
Dave X. , dans le message (digitalmars.D:172680), a écrit :
Not that this really matters, but out of curiosity, how does this
template work?
By looking at the sources, if the template argument is a string, the
program just compute the octal value as a human would do, that is it
makes the
That sounds reasonable and justified. Let's wait to know if people
maintaining legacy code will not strongly oppose to this.
Era Scarecrow , dans le message (digitalmars.D:172568), a écrit :
On Monday, 16 July 2012 at 21:59:17 UTC, Tommi wrote:
On Monday, 16 July 2012 at 20:22:12 UTC, Era Scarecrow wrote:
MyEnumType y = cast(MyEnumType) 42; //Error: wtf is 42 anyways?
Like the previous fellow said, it's not an
Jonathan M Davis , dans le message (digitalmars.D:172564), a écrit :
They're likely to contain a lot of stuff negation of other template
constraints. For instance,
auto func(R)(R range)
if(isForwardRange!R !isBidirectionalRange!R)
{}
auto func(R)(R range)
monarch_dodra , dans le message (digitalmars.D:172586), a écrit :
I was trying to fix a few bugs in algorithm, as well as be more
correct in template type specifiers, and I have to say: There is
a serious restraint in the definition of an outputRange.
The current definition of
Simen Kjaeraas , dans le message (digitalmars.D:172349), a écrit :
On Thu, 12 Jul 2012 16:31:34 +0200, Christophe Travert
trav...@phare.normalesup.org wrote:
By the way, would it be possible to implement an opCmp that returns a
double, to allow it to return a NaN ? That may allow to create
bearophile , dans le message (digitalmars.D:172300), a écrit :
If enumerate() is well implemented it's one way to avoid that
problem (other solutions are possible), now 'c' gets sliced, so
it doesn't start from zero:
import std.stdio;
void main() {
auto M = [[0, 0, 0, 0], [0, 0, 0,
David Piepgrass , dans le message (digitalmars.D:172164), a écrit :
Yeah, I've been planning to try and get this into D one day.
Probably
something like:
(a ?: b) - (auto __tmp = a, __tmp ? __tmp : b)
gcc used to have that extension and they dropped it...
But GCC can't control the C++
In any case, std.container already declares a make which encapsulates
constructing an object without caring whether it's a struct or class (since
some containers are one and some another), which I intend to move to
std.typecons and make work with all types. That seems a lot more useful to me
Benjamin Thaut , dans le message (digitalmars.D:172207), a écrit :
Move semantics in C++0x are quite nice for optimization purposes.
Thinking about it, it should be fairly easy to implement move semantics
in D as structs don't have identity. Therefor a move constructor would
not be
Jonas Drewsen , dans le message (digitalmars.D:172242), a écrit :
Can you identify any ambiguity with an ?. operator.
? could be the begining of a ternary operator, and . the module scope
indicator, or the beginning of a (badly) written float number.
Both case can be disambiguated by the
Roman D. Boiko , dans le message (digitalmars.D:172259), a écrit :
On Friday, 13 July 2012 at 13:46:10 UTC, David Nadlinger wrote:
I guess that this operator is only really worth it in languages
where every type is nullable, though.
David
It might mean identity (return the argument
Era Scarecrow , dans le message (digitalmars.D:172269), a écrit :
class Fruit {
int x;
class Seed {
void oneMoreToX() {
x++; //knows about Fruit.x, even if not instantiated
}
}
static class Seed2 {
void oneMoreToX() {
// x++; //fails to compile, no knowledge of
Era Scarecrow , dans le message (digitalmars.D:172272), a écrit :
Then perhaps have the inherited class within fruit?
class Fruit {
class Seed {}
class Appleseed : Seed {}
}
But then AppleSeed doesn't know about Apple
Andrei Alexandrescu , dans le message (digitalmars.D:172280), a écrit :
For Fruit.Seed it's Fruit, for AppleSeed it's Apple. This makes sense
because the Apple, which AppleSeed sees is the same object, which
Fruit.Seed sees as it's base type Fruit.
That would mean AppleSeed has two outer
David Piepgrass , dans le message (digitalmars.D:172007), a écrit :
@mutating class B : A
{
private int _x2;
public @property override x() { return _x2++; }
}
A fun() pure;
You can't cast the result of fun to immutable, because it may be a B
instance.
David Piepgrass , dans le message (digitalmars.D:172009), a écrit :
Now, I recognize and respect the benefits of transitive
immutability:
1. safe multithreading
2. allowing compiler optimizations that are not possible in C++
3. ability to store compile-time immutable literals in ROM
(3)
Jonathan M Davis , dans le message (digitalmars.D:172005), a écrit :
On Wednesday, July 11, 2012 13:46:17 Andrei Alexandrescu wrote:
I don't think they should be pure. Do you have reasons to think otherwise?
As I understand it, Walter's current plan is to require that opEquals, opCmp,
Timon Gehr , dans le message (digitalmars.D:172014), a écrit :
Thank you for taking the time.
Removing the default methods completely is actually a lot better than
making inheriting from Object optional or tweaking const beyond
recognition and/or usefulness.
I was afraid to suggest this
Mehrdad , dans le message (digitalmars.D:172012), a écrit :
On Thursday, 12 July 2012 at 04:15:48 UTC, Andrei Alexandrescu
wrote:
Required reading prior to this: http://goo.gl/eXpuX
Referenced post (for context):
The problem is not only in the constness of the argument, but
also in
its
Jonas Drewsen , dans le message (digitalmars.D:172039), a écrit :
On Wednesday, 11 July 2012 at 11:18:21 UTC, akaz wrote:
if needed, the operator !! (double exclamation mark) could be
defined.
...
Or the operator?? could be borrowed from c#
auto a = foo ?? new Foo();
is short for:
Christophe Travert, dans le message (digitalmars.D:172047), a écrit :
Jonas Drewsen , dans le message (digitalmars.D:172039), a écrit :
On Wednesday, 11 July 2012 at 11:18:21 UTC, akaz wrote:
if needed, the operator !! (double exclamation mark) could be
defined.
...
Or the operator
Jacob Carlborg , dans le message (digitalmars.D:172056), a écrit :
On 2012-07-12 13:35, Jonas Drewsen wrote:
Or the operator?? could be borrowed from c#
auto a = foo ?? new Foo();
is short for:
auto a = foo is null ? new Foo() : foo;
/Jonas
I really like that operator. The
Thiez , dans le message (digitalmars.D:172060), a écrit :
Have you considered adding operator overloading using UFCS
while you're at it?
I assumed it's already possible to add operators
non-intrusively, because operators are just syntactic sugar for
method calls:
++var; //
Jonathan M Davis , dans le message (digitalmars.D:172156), a écrit :
On Thursday, July 12, 2012 18:25:03 David Piepgrass wrote:
I'm putting this in a separate thread from
http://forum.dlang.org/thread/uufohvapbyceuaylo...@forum.dlang.org
because my counterproposal brings up a new issue, which
Timon Gehr , dans le message (digitalmars.D:171814), a écrit :
On 07/11/2012 01:16 AM, deadalnix wrote:
On 09/07/2012 10:14, Christophe Travert wrote:
deadalnix , dans le message (digitalmars.D:171330), a écrit :
D isn't 100% CFG. But it is close.
What makes D fail to be a CFG?
type
Andrei Alexandrescu , dans le message (digitalmars.D:171828), a écrit :
On 7/10/12 5:19 PM, H. S. Teoh wrote:
There is value in immutable objects that has been well discussed, which
is incompatible with logical constness. We can change the language such
as: a given type X has the option to
monarch_dodra , dans le message (digitalmars.D:171868), a écrit :
I'm wondering if this is the correct behavior? In particular,
since foreach guarantees a call to opSlice(), so writing arr[]
*should* be redundant, yet the final behavior is different.
That said, the issue *could* be fixed
monarch_dodra , dans le message (digitalmars.D:171902), a écrit :
I just re-read the docs you linked to, and if that was my only
source, I'd reach the same conclusion as you.
I think the reference spec for D should be the community driven and
widely available website, not a commercial book.
Andrei Alexandrescu , dans le message (digitalmars.D:171945), a écrit :
On 7/11/12 1:40 PM, Jakob Ovrum wrote:
Some classes don't lend themselves to immutability. Let's take something
obvious like a class object representing a dataset in a database. How is
an immutable instance of such a class
Jacob Carlborg , dans le message (digitalmars.D:171685), a écrit :
I mean, is it possible to have the original code work?
auto bar = foo.chain(bar);
Or perhaps more appropriate:
auto bar = foo.append(bar);
What is wrong with foo.chain([bar])?
If you do not want the heap allocation of
Dmitry Olshansky , dans le message (digitalmars.D:171679), a écrit :
Because uniq work only on sorted ranges? Have you tried reading docs?
Iterates unique consecutive elements of the given range (functionality
akin to the uniq system utility). Equivalence of elements is assessed by
using
Simen Kjaeraas , dans le message (digitalmars.D:171678), a écrit :
Well, I haven't been able to use a single function from std.algorithm
without adding a lot of calls to array or to!(string). I think the
things I'm trying to do seems trivial and quite common. I'm I overrating
Jacob Carlborg , dans le message (digitalmars.D:171690), a écrit :
int[] arr = [ 1, 2, 2, 2, 2, 3, 4, 4, 4, 5 ];
assert(equal(uniq(arr), [ 1, 2, 3, 4, 5 ][]));
How should I know that from the example?
Maybe there should be an example with an unsorted range, and a better
explanation:
|
Andrei Alexandrescu , dans le message (digitalmars.D:171717), a écrit :
On 7/10/12 11:11 AM, Christophe Travert wrote:
If you do not want the heap allocation of the array, you can create a
one-element range to feed to chain (maybe such a thing could be placed
in phobos, next to takeOne
Andrei Alexandrescu , dans le message (digitalmars.D:171723), a écrit :
auto emptyRange(E)(E value)
{
return repeat(value).takeNone;
}
That also seems to answer Jonathan's quest about defining emptyRange.
Just use takeNone(R.init).
err, that should be more like:
auto
Daniel Murphy , dans le message (digitalmars.D:171720), a écrit :
Could it be extended to accept multiple values? (sort of like chain)
eg.
foreach(x; makeRange(23, 7, 1990)) // NO allocations!
{
}
I would use this in a lot of places I currently jump through hoops to get a
static
Jacob Carlborg , dans le message (digitalmars.D:171725), a écrit :
On 2012-07-10 17:11, Christophe Travert wrote:
What is wrong with foo.chain([bar])?
I think it conceptually wrong for what I want to do. I don't know if I
misunderstood ranges completely but I'm seeing them
Jacob Carlborg , dans le message (digitalmars.D:171739), a écrit :
On 2012-07-10 18:42, Daniel Murphy wrote:
Jacob Carlborg d...@me.com wrote in message
news:jthlpf$2pnb$1...@digitalmars.com...
Can't map and filter return a random-access range if that's what they
receive?
map can, and
Daniel Murphy , dans le message (digitalmars.D:171741), a écrit :
Christophe Travert trav...@phare.normalesup.org wrote in message
news:jthmu8$2s5b$1...@digitalmars.com...
Daniel Murphy , dans le message (digitalmars.D:171720), a écrit :
Could it be extended to accept multiple values? (sort
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
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
Jacob Carlborg , dans le message (digitalmars.D.announce:23893), a
écrit :
What do people do in OC makefiles?
With Clang you can use the -ObjC or -x objective-c flags. But I guess
most people use Xcode and not makefiles.
CtoD ?
I'll have to think about it.
--
/Jacob Carlborg
deadalnix , dans le message (digitalmars.D:171330), a écrit :
D isn't 100% CFG. But it is close.
What makes D fail to be a CFG?
If you really don't need the value, you could devise a justPop method
that does not return (by the way, overloading by return type would be an
amazing feature here). The idea is not we should return a value
everytime we pop, but we should pop when we return a value.
--
Christophe
monarch_dodra , dans le message (digitalmars.D:171175), a écrit :
For those few algorithms that work on bidirRange, we'd need a
garantee that they don't ever front/back the same item twice. We
*could* achieve this by defining a bidirectionalInputRange class
of range.
filter does that. If
Denis Shelomovskij , dans le message (digitalmars.D:171072), a écrit :
Since issue 8185 has been closed, I'm still very confused. I just
understood that endless discussion doesn't result in anything.
See example from http://d.puremagic.com/issues/show_bug.cgi?id=8185#c40
---
int f(size_t
Roman D. Boiko , dans le message (digitalmars.D:171108), a écrit :
What is error-prone in current client code?
If particular algorithm wants to take advantage of a potential
speed-up, it may decide to check whether hasConsume!Range, and
call consumeFront instead of front + popFront.
takeFront implementation is dangerous for ranges which invalidates their
front value when popFront is called, for instance, File.byLine. Thus
takeFront will have to be used with care: any range implement takeFront
(because of the template and USFC), but it may not be valid. That makes
the
Range have been designed with the idea that front is valid until next
call to popFront. If popFront was to be called right after front, then
it would just be a popFront that returns a value, and maybe a justPop or
something if you don't want to copy the value.
It's delicate to come now and
Have you had a look at dcollection ?
http://www.dsource.org/projects/dcollections
There is a doubly linked list implementation, with range and cursors
(entities that have iterator functionalities).
bearophile , dans le message (digitalmars.D:171013), a écrit :
It's not a bug, it's caused by how ranges like retro work. retro
yields a single item. In D you can't overload on return values,
But you can overload OpApply.
--
Christophe
1 - 100 of 149 matches
Mail list logo
