[Issue 11834] std.net.curl: ddoc warnings
https://issues.dlang.org/show_bug.cgi?id=11834 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #2 from hst...@quickfur.ath.cx --- https://github.com/D-Programming-Language/phobos/pull/2427 --
[Issue 13204] recursive alias declaration
https://issues.dlang.org/show_bug.cgi?id=13204 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/44fe178acefdf45f56d42bbad582c42f412c78e1 fix Issue 13204 - recursive alias declaration https://github.com/D-Programming-Language/dmd/commit/83e0a9919cc07f6de2b76111878ef1905fbcaf3f Merge pull request #3822 from 9rnsr/fix13204 Issue 13204 - recursive alias declaration --
[Issue 11834] std.net.curl: ddoc warnings
https://issues.dlang.org/show_bug.cgi?id=11834 --- Comment #1 from hst...@quickfur.ath.cx --- The ddoc appears to be documenting the parameters to a delegate parameter to the function, so arguably the use of Params: is abusive for this purpose. --
[Issue 11834] std.net.curl: ddoc warnings
https://issues.dlang.org/show_bug.cgi?id=11834 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 11833] std.process: ddoc warnings
https://issues.dlang.org/show_bug.cgi?id=11833 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED CC||hst...@quickfur.ath.cx Resolution|--- |DUPLICATE --- Comment #2 from hst...@quickfur.ath.cx --- *** This issue has been marked as a duplicate of issue 13270 *** --
[Issue 13270] ddoc can't find parameters of ditto'd function overloads
https://issues.dlang.org/show_bug.cgi?id=13270 hst...@quickfur.ath.cx changed: What|Removed |Added CC||and...@erdani.com --- Comment #1 from hst...@quickfur.ath.cx --- *** Issue 11833 has been marked as a duplicate of this issue. *** --
[Issue 9728] Ddoc anchors non-unique across overloads
https://issues.dlang.org/show_bug.cgi?id=9728 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- https://github.com/D-Programming-Language/dmd/pull/3862 --
[Issue 13291] unittest should be allowed inside template functions
https://issues.dlang.org/show_bug.cgi?id=13291
--- Comment #6 from timon.g...@gmx.ch ---
(In reply to Andrei Alexandrescu from comment #5)
> (In reply to timon.gehr from comment #4)
> > (In reply to Andrei Alexandrescu from comment #3)
> > > Honest I did think of the template/eponymous trick but was too lazy to
> > > open
> > > it for discussion... there would be issues of overloading etc. left to
> > > solve
> > > with that one.
> >
> > What are those issues?
>
> I'm thinking of (a) putting two or more overloads inside the same template -
> then the unittest can't distinguish which is being instantiated (arguably
> that could be considered a mistaken us);
(The new syntax does not allow this.)
> (b) would overloading a template
> with a generic function just work?
>
> template fun(T) { void fun(T, int); }
> void fun(T)(T, double);
>
> Tried this, does work. I wonder if it works for all overloading cases.
There is no case where e.g.
void foo(T)(T arg){ ... }
behaves differently from e.g.
template foo(T){ void foo(T arg){ ... } }
The former is lowered to the latter (DMD does this in the parser AFAIK).
The way to implement the new syntax would be to simply lower it to something of
the form of the example in comment #1.
--
[Issue 13291] unittest should be allowed inside template functions
https://issues.dlang.org/show_bug.cgi?id=13291
--- Comment #5 from Andrei Alexandrescu ---
(In reply to timon.gehr from comment #4)
> (In reply to Andrei Alexandrescu from comment #3)
> > Honest I did think of the template/eponymous trick but was too lazy to open
> > it for discussion... there would be issues of overloading etc. left to solve
> > with that one.
>
> What are those issues?
I'm thinking of (a) putting two or more overloads inside the same template -
then the unittest can't distinguish which is being instantiated (arguably that
could be considered a mistaken us); (b) would overloading a template with a
generic function just work?
template fun(T) { void fun(T, int); }
void fun(T)(T, double);
Tried this, does work. I wonder if it works for all overloading cases.
--
[Issue 13291] unittest should be allowed inside template functions
https://issues.dlang.org/show_bug.cgi?id=13291 --- Comment #4 from timon.g...@gmx.ch --- (In reply to Andrei Alexandrescu from comment #3) > Honest I did think of the template/eponymous trick but was too lazy to open > it for discussion... there would be issues of overloading etc. left to solve > with that one. What are those issues? --
[Issue 13291] unittest should be allowed inside template functions
https://issues.dlang.org/show_bug.cgi?id=13291 --- Comment #3 from Andrei Alexandrescu --- Honest I did think of the template/eponymous trick but was too lazy to open it for discussion... there would be issues of overloading etc. left to solve with that one. --
[Issue 13291] unittest should be allowed inside template functions
https://issues.dlang.org/show_bug.cgi?id=13291 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86 |All --- Comment #2 from Walter Bright --- (In reply to timon.gehr from comment #1) > I.e. this enhancement suggests a shorthand syntax. And it suggests a "lowering" method of implementing it that is just a rewrite. --
[Issue 4660] Different writeln output for lazy sequences
https://issues.dlang.org/show_bug.cgi?id=4660
bearophile_h...@eml.cc changed:
What|Removed |Added
Assignee|and...@erdani.com |nob...@puremagic.com
--- Comment #3 from bearophile_h...@eml.cc ---
(In reply to hsteoh from comment #2)
> Current workaround:
>
> writefln("[%(%s; %)]", r);
>
> Is this acceptable?
It's a simple workaround, but it misses my point: I have suggested to print
lazy sequences using ";" as items separator to help the programmer tell apart
lazy sequences from arrays (and array-like) data structures. So the purpose of
using ";" is to give more information to the programmer that sees a textual
output. If you use "[%(%s; %)]" to format a lazy range, you already know that
you are dealing with a lazy range, so the textual output is not giving you much
new information. So I think if we want to change this, it has to be a built-in
feature of writeln. Otherwise we can close down this ER as wontfix, because
it's not terribly important.
--
[Issue 13291] unittest should be allowed inside template functions
https://issues.dlang.org/show_bug.cgi?id=13291
timon.g...@gmx.ch changed:
What|Removed |Added
CC||timon.g...@gmx.ch
--- Comment #1 from timon.g...@gmx.ch ---
(In reply to Andrei Alexandrescu from comment #0)
> there's no way to instantiate and fire a unittest for each instantiation of a
> function template.
This is actually not true (also pointed out by Meta on the forum):
template fun(T){
void fun(T arg){
... stuff ...
}
unittest{
... unittest for each T instantiated ...
}
}
I.e. this enhancement suggests a shorthand syntax.
--
[Issue 9119] [AA] Forward range addition to associative arrays.
https://issues.dlang.org/show_bug.cgi?id=9119 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords|pull| --
[Issue 11761] is(typeof(r.methodReturningThis) == typeof(r)) fails
https://issues.dlang.org/show_bug.cgi?id=11761 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #2 from hst...@quickfur.ath.cx --- https://github.com/D-Programming-Language/druntime/pull/925 --
[Issue 11761] is(typeof(r.methodReturningThis) == typeof(r)) fails
https://issues.dlang.org/show_bug.cgi?id=11761 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 13293] `typeof()` gets printed as `T()`
https://issues.dlang.org/show_bug.cgi?id=13293 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 11761] is(typeof(r.methodReturningThis) == typeof(r)) fails
https://issues.dlang.org/show_bug.cgi?id=11761 Marc Schütz changed: What|Removed |Added CC||schue...@gmx.net --- Comment #1 from Marc Schütz --- See also here, someone else got bitten by this problem too: http://forum.dlang.org/post/safrphnyjhbryejzk...@forum.dlang.org --
[Issue 13293] New: `typeof()` gets printed as `T()`
https://issues.dlang.org/show_bug.cgi?id=13293
Issue ID: 13293
Summary: `typeof()` gets printed as `T()`
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: schue...@gmx.net
>From http://forum.dlang.org/post/vtkrrkxgkzcfktyym...@forum.dlang.org:
struct Result {
public @property auto save1() {
return this;
}
public auto save2() {
return this;
}
}
pragma(msg, typeof(Result.init.save1));
pragma(msg, typeof(Result.init.save2));
This outputs:
Result
Result()
I guess the second type is supposed to represent the function? It should print
something that makes this clear, `Result()` doesn't make sense.
--
[Issue 12638] Void can be ref
https://issues.dlang.org/show_bug.cgi?id=12638 Ivan Kazmenko changed: What|Removed |Added CC||ga...@mail.ru See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=3934 --
[Issue 3934] Some untidy attributes
https://issues.dlang.org/show_bug.cgi?id=3934 Ivan Kazmenko changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=12638 --
