Re: first git commit
Andrei Alexandrescu wrote: > We've moved the entire camp to github: dmd compiler, phobos, druntime, > website, installer. > > I'm happy to report that we have our first git commit: > > https://github.com/D-Programming- Language/phobos/commit/81a4a4034aabe83d41cf2a0a202fedb428da66b6 > > > Andrei Congrats! Isn't it shiny?
Re: join
Andrei Alexandrescu wrote: > On 1/18/11 2:55 PM, so wrote: >>> 2. joiner uses an idiom that I've experimented with in the past: it >>> defines a local struct and returns it. As such, joiner's type is >>> impossible to express without auto. I find that idiom interesting for >>> many reasons, among which the simplest is that the code is terse, >>> compact, and doesn't pollute the namespace. I'm thinking we should do >>> the same for Appender - it doesn't make much sense to create an >>> Appender except by calling the appender() function. >> >> Didn't know there was a solution to namespace pollution. >> This one is a very nice idea, are you planning to use it in phobos in >> general? >> Retro, Stride... there should be many. > > I plan to, albeit cautiously. Sometimes people would want e.g. to store > a member of that type in a class. They still can by saying > typeof(joiner(...)) but we don't want to make it awkward for them. > > Andrei I do this sometimes with Appender for splitting complex construction of a string between functions. Is that bad practice? What is the alternative idiom? If possible, please reconsider making Appender an existential type.
Re: Is it true scope declarations are being removed?
scope declarations are going away because they're inherently unsafe. Pointers are inherently unsafe as well ;)
Re: Is it true scope declarations are being removed?
On Monday 24 January 2011 00:37:40 Trass3r wrote: > > scope declarations are going away because they're inherently unsafe. > > Pointers are inherently unsafe as well ;) Well, you can't take those out of the core language and put them in the standard library. And there _are_ cases where pointers are perfectly safe. It's pointer arithmetic and taking the addresso of a local variable which is unsafe. Those are going to be restricted to SafeD. Andrei decided that scope was too unsafe to have in the language (and presumably Walter agreed) and it _can_ be put into the standard library. If you have a problem with it, take it up with him. - Jonathan M Davis
Re: join
Andrei Alexandrescu wrote: ... > Good idea, done. Will be part of the next commit. I plan to make one > more pass through std.algorithm anyway. If there's stuff you wish were > there (including stuff generalized from other modules), please let me > know. > > > Andrei I had need for a group() that constructs a range of ranges instead of tuple with count.
Encoding problems with dsss.exe and implib.exe
For some months dsss.exe and implib.exe worked correctly on my machine. Now one of other programs has updated registry settings, I guess, and as a result when using dsss I got '4invalid UTF-8 sequence', when using implib with the arguments string "implib/system A.lib A.dll " there is the output: " IMPLIB: error IM4601: unrecognized option '/system'; option ignored "; though, when using dmd itself everything is strangely OK. The question is simple: how to restore now all the previous (good) settings on Windows XP Professional (32 bits)? There might be an inner format changed, since even text converted with Notepad++ into UTF-8 seems to be not good...
Re: first git commit
On 2011-01-24 05:51, Andrej Mitrovic wrote: I like the new diff. Although there doesn't seem to be syntax highlighting (or is that usual for diffs?). Anyway, congrats! Yes, I never seen syntax highlighting for the language in diffs. It's just the actual diff that gets highlighted, green for added and red for removed. -- /Jacob Carlborg
Re: first git commit
Andrei: > We've moved the entire camp to github: dmd compiler, phobos, druntime, > website, installer. Very good Andrei, this is another little step forward for D. May the Fork be with you :-) Bye, bearophile
Re: Is it true scope declarations are being removed?
bearophile Wrote: > If you remove it, you will have plenty of time in future to add it back, add > something better implementation of it, or to find a better and very different > solution, or even to add a more general language feature that allows you to > implement the original half-broken feature in library code. Having plenty of time, algol must be perfect now.
Re: Encoding problems with dsss.exe and implib.exe
I have to add the following to my post:
In Phobos for dmd version 1 there is only one
obvious source of this exception. Namely, it is
function 'decode' in the std.utf module.
Here is its listing:
/***
* Decodes and returns character starting at s[idx]. idx is advanced past the
* decoded character. If the character is not well formed, a UtfException is
* thrown and idx remains unchanged.
*/
dchar decode(char[] s, inout size_t idx)
in
{
assert(idx >= 0 && idx < s.length);
}
out (result)
{
assert(isValidDchar(result));
}
body
{
size_t len = s.length;
dchar V;
size_t i = idx;
char u = s[i];
if (u & 0x80)
{ uint n;
char u2;
/* The following encodings are valid, except for the 5 and 6 byte
* combinations:
* 0xxx
* 110x 10xx
* 1110 10xx 10xx
* 0xxx 10xx 10xx 10xx
* 10xx 10xx 10xx 10xx 10xx
* 110x 10xx 10xx 10xx 10xx 10xx
*/
for (n = 1; ; n++)
{
if (n > 4)
goto Lerr; // only do the first 4 of 6 encodings
if (((u << n) & 0x80) == 0)
{
if (n == 1)
goto Lerr;
break;
}
}
// Pick off (7 - n) significant bits of B from first byte of octet
V = cast(dchar)(u & ((1 << (7 - n)) - 1));
if (i + (n - 1) >= len)
goto Lerr; // off end of string
/* The following combinations are overlong, and illegal:
* 110x (10xx)
* 1110 100x (10xx)
* 1000 (10xx 10xx)
* 1000 1xxx (10xx 10xx 10xx)
* 1100 10xx (10xx 10xx 10xx 10xx)
*/
u2 = s[i + 1];
if ((u & 0xFE) == 0xC0 ||
(u == 0xE0 && (u2 & 0xE0) == 0x80) ||
(u == 0xF0 && (u2 & 0xF0) == 0x80) ||
(u == 0xF8 && (u2 & 0xF8) == 0x80) ||
(u == 0xFC && (u2 & 0xFC) == 0x80))
goto Lerr; // overlong combination
for (uint j = 1; j != n; j++)
{
u = s[i + j];
if ((u & 0xC0) != 0x80)
goto Lerr; // trailing bytes are 10xx
V = (V << 6) | (u & 0x3F);
}
if (!isValidDchar(V))
goto Lerr;
i += n;
}
else
{
V = cast(dchar) u;
i++;
}
idx = i;
return V;
Lerr:
//printf("\ndecode: idx = %d, i = %d, length = %d s =
\n'%.*s'\n%x\n'%.*s'\n",
idx, i, s.length, s, s[i], s[i .. length]);
throw new UtfException("4invalid UTF-8 sequence", i);
}
In no other place was found text "4invalid UTF-8 sequence",
therefore, this function needs a revision.
So, I myself answered to the question that concerns the dsss behavior,
as dsss is written in D. But the strange behaviour of implib still undefined.
Re: Encoding problems with dsss.exe and implib.exe
Vitaly Kulich Wrote: > For some months dsss.exe and implib.exe worked correctly on my machine. Now > one of other programs has updated registry settings, I guess Photoshop encoding fix?
Will D ever get to a true 1.0 release? When?
The question in the prompted from this bear post: bearophile wrote: > Andrej Mitrovic: > >> I don't understand it either. AFAIK they are being removed because >> they're unsafe, and are being replaced by an unsafe library solution. > > I have hated see typedef and scoped classes go (I have even missed > delete), but you need a bit of faith in the future and in Andrei & > Walter. Andrei is not evil, and he's smart. D2 language is a very > young language, and when a built-in feature looks not perfect, it's > better to remove it now. If you remove it, you will have plenty of > time in future to add it back, add something better implementation of > it, or to find a better and very different solution, or even to add a > more general language feature that allows you to implement the > original half-broken feature in library code. While if something > badly designed is left in the language, then you are struck with it > forever, or almost forever. Generally in language it's 10-100 times > simpler to add a new feature than to remove it :-) Better to start > with a not complete D2 language, a language with holes waiting to be > filled, that with a language with unfixable warts that you may "fix" > just adding another better feature and pretending the old one doesn't > exist any more (example: nullptr of C++0x). Will D ever get to a true 1.0 release? If so, when? Specifying 1.0 and 2.0 seems rather gratuitous (or typos?). More appropriate may indeed be 0.1 and 0.2. All the hand-waving about this great new automobile, yet it has no wheels, or square ones!
Re: Will D ever get to a true 1.0 release? When?
Rob: > Will D ever get to a true 1.0 release? If so, when? Specifying 1.0 and > 2.0 seems rather gratuitous (or typos?). More appropriate may indeed be > 0.1 and 0.2. All the hand-waving about this great new automobile, yet it > has no wheels, or square ones! Some smal parts of the D2 design are unfinished, and surely some more parts may be added to create a future D3, but D2 design is mostly finished. Bye, bearophile
Re: Is it true scope declarations are being removed?
On Sun, 23 Jan 2011 19:03:19 -0500, so wrote: On Mon, 24 Jan 2011 00:11:48 +0200, Trass3r wrote: Sadly true. They intend to replace it with a library based solution, I don't know why. If the library solution is as good as the original, it is a big plus. If only we could do the same for everything! In fact the library solution will be better, because it's an expression, not a storage class. This means, you can "scope" a class inside another statement instead of having to declare/initialize it separately. It solves a bug I filed: http://d.puremagic.com/issues/show_bug.cgi?id=2070 -Steve
const/immutable member functions
class F
{
const Foo bar();
}
Isn't this ambiguous? "returns a const Foo object" vs. "is a const
member function that returns a Foo object"?
Re: join
18.01.2011 22:25, Andrei Alexandrescu пишет: I implemented a simple separatorless joiner as follows: ... The code has a few properties that I'd like to discuss a bit: 2. joiner uses an idiom that I've experimented with in the past: it defines a local struct and returns it. As such, joiner's type is impossible to express without auto. I find that idiom interesting for many reasons, among which the simplest is that the code is terse, compact, and doesn't pollute the namespace. I'm thinking we should do the same for Appender - it doesn't make much sense to create an Appender except by calling the appender() function. I somewhat disagree about Appender. I had situations when I needed to store an Appender as a class/struct member (i.e. one may build an output range on top of it). Appender!T looks better than ReturnType!(appender!T()), IMHO. Of course, one could always alias that ReturnType, so it's not *that* much of a problem.
Re: const/immutable member functions
Trass3r wrote:
class F
{
const Foo bar();
}
Isn't this ambiguous? "returns a const Foo object" vs. "is a const
member function that returns a Foo object"?
Only to humans. const applies to everything after it, unless there
are parentheses. In this case, 'everything' is Foo bar();
I do agree it is ambiguous though, and should be disallowed, or at
very least, discouraged.
--
Simen
Re: const/immutable member functions
On Monday 24 January 2011 05:56:49 Trass3r wrote:
> class F
> {
> const Foo bar();
> }
>
> Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> member function that returns a Foo object"?
When using const or immutable in a function signature, it _always_ applies to
the function, unless you use parens to say otherwise.
const Foo bar(); //const function
Foo bar() const; //const function
immutable Foo bar(); //immutable function
Foo bar() immutable; //immutable function
const(Foo) bar(); //mutable function with const return value
const(Foo) bar() const; //const function with const return value
immutable(Foo) bar(); //mutable function with immutable return value
immutable(Foo) bor() immutable; //immutable function with immutable return value
And, of course, you could mix up const and immutable to have const functions
with immutable return values and vice versa.
Personally, I don't like it. In fact, most people don't, but that's the way it
is. I always put const and immutable or the right-hand side of the function
when
I want the function to be const or immutable, and I wish that that were
required, but it isn't. It's the way it is because it's consistent with all of
the other function modifiers: @property, nothrow, public, static, etc. In fact,
ddoc always put them all in front of the function signature, even if you put
them after.
So, if you want the return value to be const or immutable, use parens.
Otherwise
it's the function. If you want both to be const and/or immutable, then you need
to mark them both that way.
- Jonathan M Davis
Re: const/immutable member functions
On Monday 24 January 2011 06:02:13 Simen kjaeraas wrote:
> Trass3r wrote:
> > class F
> > {
> > const Foo bar();
> > }
> >
> > Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> > member function that returns a Foo object"?
>
> Only to humans. const applies to everything after it, unless there
> are parentheses. In this case, 'everything' is Foo bar();
Not quite right. The return value is _not_ const in this case. It's only the
function which is affected. Try it and you'll see. The _only_ time that a
return
value is const or immutable is if you use parens to mark it that way.
- Jonathan M Davis
Re: const/immutable member functions
Simen kjaeraas wrote:
> Trass3r wrote:
>
> >class F
> >{
> >const Foo bar();
> >}
> >
> >Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> >member function that returns a Foo object"?
>
> Only to humans. const applies to everything after it, unless there
> are parentheses. In this case, 'everything' is Foo bar();
>
> I do agree it is ambiguous though, and should be disallowed, or at
> very least, discouraged.
Very true.
Preferred style is to write
Foo bar() const;
Jens
Re: const/immutable member functions
On Mon, 24 Jan 2011 09:20:17 -0500, Jonathan M Davis
wrote:
On Monday 24 January 2011 05:56:49 Trass3r wrote:
class F
{
const Foo bar();
}
Isn't this ambiguous? "returns a const Foo object" vs. "is a const
member function that returns a Foo object"?
When using const or immutable in a function signature, it _always_
applies to
the function, unless you use parens to say otherwise.
const Foo bar(); //const function
Foo bar() const; //const function
immutable Foo bar(); //immutable function
Foo bar() immutable; //immutable function
const(Foo) bar(); //mutable function with const return value
const(Foo) bar() const; //const function with const return value
immutable(Foo) bar(); //mutable function with immutable return value
immutable(Foo) bor() immutable; //immutable function with immutable
return value
You forget my favorite:
const const Foo bar(); // const function returning const Foo.
-Steve
std.unittests [updated] for review
In case you didn't know, I have a set of unit test helper functions which have been being reviewed for possible inclusion in phobos. Here's an update. Most recent code: http://is.gd/F1OHat Okay. I took the previous suggestions into consideration and adjusted the code a bit more. However, most of the changes are to the documentation (though there are some changes to the code). Some of the code duplication was removed, and the way that some of the assertPred functions' errors are formatted has been altered so that values line up vertically, making them easier to compare. The big change is the docs though. There's now a fake version of assertPred at the top with an overall description for assertPred followed by the individual versions with as little documentation as seemed appropriate while still getting all of the necessary information across. A couple of the functions still have irritatingly long example sections, but anything less wouldn't get the functionality across. In any case. Here's the updated code. Review away. Andrei set the vote deadline for February 7th, at which point, if it passes majority vote, then it will go into Phobos. The number of functions is small enough now (thanks to having consolidated most of them into the fantastically versatile assertPred) that it looks like it will likely go in std.exception if the vote passes rather than becoming a new module. So, the std.unittests title has now become a bit of a misnomer, but that's what I've been calling it, so it seemed appropriate to continue to label it that way in the thread's title. - Jonathan M Davis
Re: const/immutable member functions
On Monday 24 January 2011 06:27:34 Steven Schveighoffer wrote:
> On Mon, 24 Jan 2011 09:20:17 -0500, Jonathan M Davis
>
> wrote:
> > On Monday 24 January 2011 05:56:49 Trass3r wrote:
> >> class F
> >> {
> >> const Foo bar();
> >> }
> >>
> >> Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> >> member function that returns a Foo object"?
> >
> > When using const or immutable in a function signature, it _always_
> > applies to
> > the function, unless you use parens to say otherwise.
> >
> > const Foo bar(); //const function
> > Foo bar() const; //const function
> > immutable Foo bar(); //immutable function
> > Foo bar() immutable; //immutable function
> > const(Foo) bar(); //mutable function with const return value
> > const(Foo) bar() const; //const function with const return value
> > immutable(Foo) bar(); //mutable function with immutable return value
> > immutable(Foo) bor() immutable; //immutable function with immutable
> > return value
>
> You forget my favorite:
>
> const const Foo bar(); // const function returning const Foo.
That works? I would have thought that it still would have required the parens.
Regardless, const and immutable on functions is not the cleanest corner of D.
It's fairly easily understood and mostly doesn't result in bugs because marking
the wrong thing as const usually results in a compilation error somewhere, but
still, it would be nice if const and immutable had to go on the right-hand side
like they do in C++.
- Jonathan M Davis
Re: Is it true scope declarations are being removed?
On 1/24/11, Steven Schveighoffer wrote: > This means, you can "scope" a class inside another statement instead of > having to declare/initialize it separately. It solves a bug I filed: > > http://d.puremagic.com/issues/show_bug.cgi?id=2070 > > -Steve > That is pretty cool. What I worried about is that a library solution could mean loosing help from the compiler itself. E.g. if the compiler sees a scoped variable it can do some checks to see that you're not escaping a reference by accident, inadvertently assigning it to a global, or some other sanity checks. I guess these things might be doable in a library but I don't know to what extent.
Re: const/immutable member functions
Perhaps it would be less ambiguous if we turned const/immutable for functions into annotations: @const Foo bar(); //const function @immutable Foo bar(); //immutable function @immutable const(Foo) bar(); //immutable function with const return value @const const(Foo) bar(); //const function with const return value immutable(Foo) bar(); //mutable function with immutable return value @immutable immutable(Foo) bor(); //immutable function with immutable return value But I'm not a big fan of "@", it clutters up source code.
Re: const/immutable member functions
On Monday 24 January 2011 06:45:27 Andrej Mitrovic wrote: > Perhaps it would be less ambiguous if we turned const/immutable for > functions into annotations: > > @const Foo bar(); //const function > @immutable Foo bar(); //immutable function > @immutable const(Foo) bar(); //immutable function with const return value > @const const(Foo) bar(); //const function with const return value > immutable(Foo) bar(); //mutable function with immutable return value > @immutable immutable(Foo) bor(); //immutable function with immutable > return value > > But I'm not a big fan of "@", it clutters up source code. Well, any change to the situation would break TDPL, I believe, so we're pretty much stuck. If Walter didn't think it was bad enough to fix by now, he won't fix it post-TDPL. - Jonathan M Davis
Re: std.unittests [updated] for review
On Monday 24 January 2011 06:34:49 Jonathan M Davis wrote: > In case you didn't know, I have a set of unit test helper functions which > have been being reviewed for possible inclusion in phobos. Here's an > update. > > Most recent code: http://is.gd/F1OHat > > Okay. I took the previous suggestions into consideration and adjusted the > code a bit more. However, most of the changes are to the documentation > (though there are some changes to the code). Some of the code duplication > was removed, and the way that some of the assertPred functions' errors are > formatted has been altered so that values line up vertically, making them > easier to compare. The big change is the docs though. There's now a fake > version of assertPred at the top with an overall description for > assertPred followed by the individual versions with as little > documentation as seemed appropriate while still getting all of the > necessary information across. A couple of the functions still have > irritatingly long example sections, but anything less wouldn't get the > functionality across. > > In any case. Here's the updated code. Review away. Andrei set the vote > deadline for February 7th, at which point, if it passes majority vote, > then it will go into Phobos. The number of functions is small enough now > (thanks to having consolidated most of them into the fantastically > versatile assertPred) that it looks like it will likely go in > std.exception if the vote passes rather than becoming a new module. So, > the std.unittests title has now become a bit of a misnomer, but that's > what I've been calling it, so it seemed appropriate to continue to label > it that way in the thread's title. > > - Jonathan M Davis By the way, I should point out that this requires the newest (now git!) version of druntime to work, since I made assertThrown chain the exception which was thrown to the AssertError on failure. It doesn't do much good at the moment, since only the AssertError gets printed, but maybe that'll change at some point. Regardless, I had to make it so that AssertError would take another Throwable for it to work, so you'll need the version from the git repository ( https://github.com/D-Programming-Language/druntime ) for it work. The examples (and therefore the unit tests) require the git version of Phobos as well ( https://github.com/D-Programming-Language/phobos ), since some of them use std.datetime. The code itself doesn't require a newer version of Phobos though. - Jonathan M Davis
Re: Is it true scope declarations are being removed?
On Mon, 24 Jan 2011 09:41:30 -0500, Andrej Mitrovic wrote: On 1/24/11, Steven Schveighoffer wrote: This means, you can "scope" a class inside another statement instead of having to declare/initialize it separately. It solves a bug I filed: http://d.puremagic.com/issues/show_bug.cgi?id=2070 -Steve That is pretty cool. What I worried about is that a library solution could mean loosing help from the compiler itself. E.g. if the compiler sees a scoped variable it can do some checks to see that you're not escaping a reference by accident, inadvertently assigning it to a global, or some other sanity checks. I guess these things might be doable in a library but I don't know to what extent. That wasn't done by the compiler anyways. -Steve
Re: const/immutable member functions
On Mon, 24 Jan 2011 09:39:16 -0500, Jonathan M Davis
wrote:
On Monday 24 January 2011 06:27:34 Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 09:20:17 -0500, Jonathan M Davis
wrote:
> On Monday 24 January 2011 05:56:49 Trass3r wrote:
>> class F
>> {
>> const Foo bar();
>> }
>>
>> Isn't this ambiguous? "returns a const Foo object" vs. "is a const
>> member function that returns a Foo object"?
>
> When using const or immutable in a function signature, it _always_
> applies to
> the function, unless you use parens to say otherwise.
>
> const Foo bar(); //const function
> Foo bar() const; //const function
> immutable Foo bar(); //immutable function
> Foo bar() immutable; //immutable function
> const(Foo) bar(); //mutable function with const return value
> const(Foo) bar() const; //const function with const return value
> immutable(Foo) bar(); //mutable function with immutable return value
> immutable(Foo) bor() immutable; //immutable function with immutable
> return value
You forget my favorite:
const const Foo bar(); // const function returning const Foo.
That works? I would have thought that it still would have required the
parens.
I could have sworn it does, but on testing (which I probably should have
done), it fails (even back on 2.033) with:
redundant storage class const
Sorry for the noise, I still find the const const(Foo) bar() very
confusing to read.
-Steve
Re: first git commit
== Quote from Caligo (iteronve...@gmail.com)'s article > --000e0cd2df0ab55eda049a91f318 > Content-Type: text/plain; charset=ISO-8859-1 > On Sun, Jan 23, 2011 at 10:14 PM, Andrei Alexandrescu < > seewebsiteforem...@erdani.org> wrote: > > We've moved the entire camp to github: dmd compiler, phobos, druntime, > > website, installer. > > > > I'm happy to report that we have our first git commit: > > > > > > https://github.com/D-Programming- Language/phobos/commit/81a4a4034aabe83d41cf2a0a202fedb428da66b6 > > > > > > Andrei > > > > > What about the GDC team? Are they planning to switch to Git as well? What do we have to do with this? I don't think we have much to gain from moving to git. It's not likely to have much effect on the level of interest people have towards contributing anyway. I could ask around, they'd probably tell me to fork off though. 8-)
Re: std.unittests [updated] for review
Maybe if we get that "any" function any time soon (pardon the pun), we
could simplify those constraints a little bit:
enum string[] binaryOps = ["+", "-", "*", "/", "%", "^^", "&", "|",
"^", "<<", ">>", ">>>", "~"];
void assertPred(string op, L, R, E)
(L lhs, R rhs, E expected, lazy string msg = null,
string file = __FILE__, size_t line = __LINE__)
if(any(op, binaryOps) &&
__traits(compiles, mixin("lhs " ~ op ~ " rhs")) &&
__traits(compiles, mixin("(lhs " ~ op ~ " rhs) == expected")) &&
isPrintable!L &&
isPrintable!R)
{
}
I don't recall what any will look like exactly, but something like
that could work I guess.
Re: Is it true scope declarations are being removed?
On 1/24/11, Steven Schveighoffer wrote: > That wasn't done by the compiler anyways. > > -Steve > Yeah I've noticed that. Lazy DMD compiler! :)
Re: const/immutable member functions
Trass3r Wrote:
> class F
> {
> const Foo bar();
> }
>
> Isn't this ambiguous? "returns a const Foo object" vs. "is a const
> member function that returns a Foo object"?
The const qualifier applies to the member being declared - the function in this
case. Usually transitivity rules come into play, but they're not defined for
functions.
Re: std.unittests [updated] for review
On Monday 24 January 2011 07:48:25 Andrej Mitrovic wrote:
> Maybe if we get that "any" function any time soon (pardon the pun), we
> could simplify those constraints a little bit:
>
> enum string[] binaryOps = ["+", "-", "*", "/", "%", "^^", "&", "|",
> "^", "<<", ">>", ">>>", "~"];
>
> void assertPred(string op, L, R, E)
>(L lhs, R rhs, E expected, lazy string msg = null,
> string file = __FILE__, size_t line = __LINE__)
> if(any(op, binaryOps) &&
>__traits(compiles, mixin("lhs " ~ op ~ " rhs")) &&
>__traits(compiles, mixin("(lhs " ~ op ~ " rhs) == expected")) &&
>isPrintable!L &&
>isPrintable!R)
> {
> }
>
> I don't recall what any will look like exactly, but something like
> that could work I guess.
Assuming that it worked with CTFE, of course (surprisingly little in
std.algorithm works in CTFE from what I've seen). Ultimately, I don' think that
it matters all that much, since you need a list of the acceptable operators
somewhere regardless, but using any _would_ be a bit cleaner.
- Jonathan M Davis
Re: Is it true scope declarations are being removed?
On Monday 24 January 2011 07:49:44 Andrej Mitrovic wrote: > On 1/24/11, Steven Schveighoffer wrote: > > That wasn't done by the compiler anyways. > > > > -Steve > > Yeah I've noticed that. Lazy DMD compiler! :) Much of anything that requires code flow analysis doesn't tend to happen. And it's so easy to get around it in many cases (such as passing a pointer to a function which then returns that pointer) that it wouldn't ultimately help all that much anyway (though having _some_ is still better than nothing). The fact that such things can't be reliably verified at compile time is exactly why scoped classes are unsafe in the first place. - Jonathan M Davis
Re: const/immutable member functions
Jonathan M Davis wrote: Only to humans. const applies to everything after it, unless there are parentheses. In this case, 'everything' is Foo bar(); Not quite right. The return value is _not_ const in this case. It's only the function which is affected. Try it and you'll see. The _only_ time that a return value is const or immutable is if you use parens to mark it that way. I could probably have worded that more clearly. *clears throat* const applies to one, and exactly one, thing after it, matched greedily. So yes, Foo bar() is the 'everything'. Foo and Foo bar() would be two things. -- Simen
Re: Will D ever get to a true 1.0 release? When?
Rob Wrote: > Will D ever get to a true 1.0 release? If so, when? Specifying 1.0 and > 2.0 seems rather gratuitous (or typos?). More appropriate may indeed be > 0.1 and 0.2. All the hand-waving about this great new automobile, yet it > has no wheels, or square ones! What is wrong with the current 1.0 version? If I assume your complaint is related to D2 having new features and not be backwards compatible with v1.0? Such discussions have taken place in the past and 1.0 was considered an arbitrary stopping point. But versions are pretty arbitrary anyway. The fact that it is still receiving bug fixes makes it a good candidate as a whole number version. If you are complaining about the idea that D2 has removed features without an adequate replacement. At this point it is mainly D2 can't deviate from what is written in TDPL and for the most part their is no reason to. But the compiler still needs to catch up to the book.
Re: first git commit
On Mon, 2011-01-24 at 15:37 +, Iain Buclaw wrote: [ . . . ] > What do we have to do with this? I don't think we have much to gain from > moving > to git. It's not likely to have much effect on the level of interest people > have > towards contributing anyway. If you are currently using Subversion then there is masses to be gained by moving to Git in line with the rest of the D development effort. I guess GCC itself is still Subversion? Bazaar is a GNU project, and this tipped the balance such that Emacs was pushed to shift from Subversion to Bazaar. The change caused a lot of heated aggravation between the Bazaar, Mercurial and Git advocates. Normal then ;-) I don't know which direction the GCC crew would go, but I guess GDC needs to ensure it is compatible -- though Git, Mercurial and Bazaar can always work with a Subversion repository, Bazaar in a much smoother DVCS way that the other two. > I could ask around, they'd probably tell me to fork off though. 8-) Or they might say "about forking time" ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: first git commit
On Mon, Jan 24, 2011 at 11:01 AM, Russel Winder wrote: > On Mon, 2011-01-24 at 15:37 +, Iain Buclaw wrote: > [ . . . ] > > What do we have to do with this? I don't think we have much to gain from > moving > > to git. It's not likely to have much effect on the level of interest > people have > > towards contributing anyway. > > If you are currently using Subversion then there is masses to be gained > by moving to Git in line with the rest of the D development effort. > > I guess GCC itself is still Subversion? > > Bazaar is a GNU project, and this tipped the balance such that Emacs was > pushed to shift from Subversion to Bazaar. The change caused a lot of > heated aggravation between the Bazaar, Mercurial and Git advocates. > Normal then ;-) > > I don't know which direction the GCC crew would go, but I guess GDC > needs to ensure it is compatible -- though Git, Mercurial and Bazaar can > always work with a Subversion repository, Bazaar in a much smoother DVCS > way that the other two. > > > I could ask around, they'd probably tell me to fork off though. 8-) > > Or they might say "about forking time" ;-) GDC is currently on Mercurial on Bitbucket.
Re: first git commit
On Mon, 2011-01-24 at 11:03 -0600, Andrew Wiley wrote: [ . . . ] > > GDC is currently on Mercurial on Bitbucket. In which case there seems no point in even thinking about Git and GitHub. In terms of workflow Mercurial/BitBucket and Git/GitHub are fundamentally the same. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Showing unittest in documentation (Was Re: std.unittests [updated] for review)
Jonathan M Davis wrote: > In case you didn't know, I have a set of unit test helper functions which > have > been being reviewed for possible inclusion in phobos. Here's an update. > > Most recent code: http://is.gd/F1OHat > > Okay. I took the previous suggestions into consideration and adjusted the > code a > bit more. However, most of the changes are to the documentation (though there > are some changes to the code). Some of the code duplication was removed, and > the > way that some of the assertPred functions' errors are formatted has been > altered > so that values line up vertically, making them easier to compare. The big > change > is the docs though. There's now a fake version of assertPred at the top with > an > overall description for assertPred followed by the individual versions with > as > little documentation as seemed appropriate while still getting all of the > necessary information across. A couple of the functions still have > irritatingly > long example sections, but anything less wouldn't get the functionality > across. > > In any case. Here's the updated code. Review away. Andrei set the vote > deadline > for February 7th, at which point, if it passes majority vote, then it will go > into Phobos. The number of functions is small enough now (thanks to having > consolidated most of them into the fantastically versatile assertPred) that > it > looks like it will likely go in std.exception if the vote passes rather than > becoming a new module. So, the std.unittests title has now become a bit of a > misnomer, but that's what I've been calling it, so it seemed appropriate to > continue to label it that way in the thread's title. I wonder whether there is a nice way to have unittests included in the documentation but also executed. There are lots of examples in the module (search for 'Verify Examples'). I like to avoid this duplication. Has anybody an idea how to achieve this? Often the unittests themselves are a pretty good code documentation. Jens
Re: const/immutable member functions
There are six, seven or more people that wish to do something about this situation. TDPL is the D2 reference, but few little changes over its first edition are acceptable if they improve the D language a little. - Trass3r: asks if the code is ambiguous - Jonathan M Davis: does't like it and puts const/etc on the right - Simen kjaeraas thinks it's ambiguous though, and should be disallowed, or at very least, discouraged. - Jens Mueller: Preferred style is to write const on the right - Andrej Mitrovic suggests to use @ but says it clutters up source code. - I agree with Jonathan M Davis. What other people think about this situation? Do you want const/immutable to be required on the right, or do you prefer the current situation, or do you prefer some other solution? This is the bug report, that Walter has closed, but if necessary it may be opened up again if enough people are interested in the topic: http://d.puremagic.com/issues/show_bug.cgi?id=4070 See also: http://d.puremagic.com/issues/show_bug.cgi?id=4040 Bye, bearophile
Re: const/immutable member functions
2011/1/24 bearophile :
> What other people think about this situation? Do you want const/immutable to
> be required on the right, or do you prefer the current situation, or do you
> prefer some other solution?
If const is required to go on the right, what do you do if you want to
mark a bunch of functions const inside {}?
Torarin
Re: const/immutable member functions
On Mon, 24 Jan 2011 20:41:17 +0200, Torarin wrote:
2011/1/24 bearophile :
What other people think about this situation? Do you want
const/immutable to be required on the right, or do you prefer the
current situation, or do you prefer some other solution?
If const is required to go on the right, what do you do if you want to
mark a bunch of functions const inside {}?
Torarin
I love that one, it is also quite explicit, we should definitely keep it.
But i agree with all that the other case should be disallowed.
Re: const/immutable member functions
On Mon, 24 Jan 2011 13:36:36 -0500, bearophile wrote: There are six, seven or more people that wish to do something about this situation. TDPL is the D2 reference, but few little changes over its first edition are acceptable if they improve the D language a little. - Trass3r: asks if the code is ambiguous - Jonathan M Davis: does't like it and puts const/etc on the right - Simen kjaeraas thinks it's ambiguous though, and should be disallowed, or at very least, discouraged. - Jens Mueller: Preferred style is to write const on the right - Andrej Mitrovic suggests to use @ but says it clutters up source code. - I agree with Jonathan M Davis. What other people think about this situation? Do you want const/immutable to be required on the right, or do you prefer the current situation, or do you prefer some other solution? I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined. I think we have more important problems to worry about than this. -Steve
Re: const/immutable member functions
Torarin wrote:
2011/1/24 bearophile :
What other people think about this situation? Do you want
const/immutable to be required on the right, or do you prefer the
current situation, or do you prefer some other solution?
If const is required to go on the right, what do you do if you want to
mark a bunch of functions const inside {}?
The suggestion is only for const alone on the left-hand side. const: and
const{} would not be affected by such a change.
That said, I consider const Foo bar(); to be a bug, and mercilessly
squish it. I always put const on the right side of functions, and should
I ever write coding guidelines for D, putting it on the left would be a
capital offense.
--
Simen
Re: const/immutable member functions
I think we have more important problems to worry about than this. IMHO fixing trivial issues first or as soon as possible is better. Not saying this is one of them, i mean generally.
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On Monday, January 24, 2011 09:55:52 Jens Mueller wrote: > Jonathan M Davis wrote: > > In case you didn't know, I have a set of unit test helper functions which > > have been being reviewed for possible inclusion in phobos. Here's an > > update. > > > > Most recent code: http://is.gd/F1OHat > > > > Okay. I took the previous suggestions into consideration and adjusted the > > code a bit more. However, most of the changes are to the documentation > > (though there are some changes to the code). Some of the code > > duplication was removed, and the way that some of the assertPred > > functions' errors are formatted has been altered so that values line up > > vertically, making them easier to compare. The big change is the docs > > though. There's now a fake version of assertPred at the top with an > > overall description for assertPred followed by the individual versions > > with as little documentation as seemed appropriate while still getting > > all of the necessary information across. A couple of the functions still > > have irritatingly long example sections, but anything less wouldn't get > > the functionality across. > > > > In any case. Here's the updated code. Review away. Andrei set the vote > > deadline for February 7th, at which point, if it passes majority vote, > > then it will go into Phobos. The number of functions is small enough now > > (thanks to having consolidated most of them into the fantastically > > versatile assertPred) that it looks like it will likely go in > > std.exception if the vote passes rather than becoming a new module. So, > > the std.unittests title has now become a bit of a misnomer, but that's > > what I've been calling it, so it seemed appropriate to continue to label > > it that way in the thread's title. > > I wonder whether there is a nice way to have unittests included in the > documentation but also executed. There are lots of examples in the > module (search for 'Verify Examples'). > I like to avoid this duplication. Has anybody an idea how to achieve > this? Often the unittests themselves are a pretty good code > documentation. I think that it's been discussed a time or two, but nothing has been done about it. It wouldn't be entirely straightforward to do. Essentially, either a unittest block would have to be generated from the Examples section in the documentation, or you'd have to have some way to indicate that a particular unittest block got put into the documentation as an Examples section. It's certainly true that it would be ideal to have a way to avoid the duplication, but we don't have one at the moment, and it hasn't yet been a high enough priority to sort out how to do it and implement it. - Jonathan M Davis
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
Jonathan M Davis wrote: > On Monday, January 24, 2011 09:55:52 Jens Mueller wrote: > > Jonathan M Davis wrote: > > > In case you didn't know, I have a set of unit test helper functions which > > > have been being reviewed for possible inclusion in phobos. Here's an > > > update. > > > > > > Most recent code: http://is.gd/F1OHat > > > > > > Okay. I took the previous suggestions into consideration and adjusted the > > > code a bit more. However, most of the changes are to the documentation > > > (though there are some changes to the code). Some of the code > > > duplication was removed, and the way that some of the assertPred > > > functions' errors are formatted has been altered so that values line up > > > vertically, making them easier to compare. The big change is the docs > > > though. There's now a fake version of assertPred at the top with an > > > overall description for assertPred followed by the individual versions > > > with as little documentation as seemed appropriate while still getting > > > all of the necessary information across. A couple of the functions still > > > have irritatingly long example sections, but anything less wouldn't get > > > the functionality across. > > > > > > In any case. Here's the updated code. Review away. Andrei set the vote > > > deadline for February 7th, at which point, if it passes majority vote, > > > then it will go into Phobos. The number of functions is small enough now > > > (thanks to having consolidated most of them into the fantastically > > > versatile assertPred) that it looks like it will likely go in > > > std.exception if the vote passes rather than becoming a new module. So, > > > the std.unittests title has now become a bit of a misnomer, but that's > > > what I've been calling it, so it seemed appropriate to continue to label > > > it that way in the thread's title. > > > > I wonder whether there is a nice way to have unittests included in the > > documentation but also executed. There are lots of examples in the > > module (search for 'Verify Examples'). > > I like to avoid this duplication. Has anybody an idea how to achieve > > this? Often the unittests themselves are a pretty good code > > documentation. > > I think that it's been discussed a time or two, but nothing has been done > about > it. It wouldn't be entirely straightforward to do. Essentially, either a > unittest block would have to be generated from the Examples section in the > documentation, or you'd have to have some way to indicate that a particular > unittest block got put into the documentation as an Examples section. It's > certainly true that it would be ideal to have a way to avoid the duplication, > but we don't have one at the moment, and it hasn't yet been a high enough > priority to sort out how to do it and implement it. I see. I understand that it does not have high priority. Just wondered whether ... Jens
Re: const/immutable member functions
I wouldn't say that I *prefer* the current solution, but the current
solution is not so bad that I need it changed.
It works fine, despite being confusing. If it wasn't consistent with
the rest of the attributes, I'd say it was in need of changes, but it
fits within the scheme already outlined.
I think we have more important problems to worry about than this.
-Steve
I'm not sure either but I usually use the suffix version.
The question is if there is any case where the prefix one could be harmful
(i.e. not resulting in an error message).
Maybe the following?:
class Foo
{
private static Bar[] bar;
// author thinks it returns a const pointer etc.
const Foo* ptr()
{
return bar.ptr;
}
}
Re: const/immutable member functions
Steven Schveighoffer wrote: On Mon, 24 Jan 2011 13:36:36 -0500, bearophile wrote: There are six, seven or more people that wish to do something about this situation. TDPL is the D2 reference, but few little changes over its first edition are acceptable if they improve the D language a little. - Trass3r: asks if the code is ambiguous - Jonathan M Davis: does't like it and puts const/etc on the right - Simen kjaeraas thinks it's ambiguous though, and should be disallowed, or at very least, discouraged. - Jens Mueller: Preferred style is to write const on the right - Andrej Mitrovic suggests to use @ but says it clutters up source code. - I agree with Jonathan M Davis. What other people think about this situation? Do you want const/immutable to be required on the right, or do you prefer the current situation, or do you prefer some other solution? I wouldn't say that I *prefer* the current solution, but the current solution is not so bad that I need it changed. It works fine, despite being confusing. If it wasn't consistent with the rest of the attributes, I'd say it was in need of changes, but it fits within the scheme already outlined. It's a problem for all of the other attributes as well. I wish it were disallowed for all of them. Incidentally, putting it afterwards always works. Putting it before doesn't always work, due to compiler bugs (for example, prefix 'pure' doesn't work for inner functions).
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittest block would have to be generated from the Examples section in the
documentation, or you'd have to have some way to indicate that a particular
unittest block got put into the documentation as an Examples section. It's
certainly true that it would be ideal to have a way to avoid the duplication,
but we don't have one at the moment, and it hasn't yet been a high enough
priority to sort out how to do it and implement it.
I see. I understand that it does not have high priority. Just wondered
whether ...
Jens
The change is much simpler than what Jonathan suggests. A change can be
made such that any unittest preceded by a documentation comment is
automatically considered an example.
/**
Example:
*/
unittest
{
writeln("This is how it works.");
}
Andrei
Re: std.unittests [updated] for review
"Jonathan M Davis" wrote in message news:mailman.888.1295879701.4748.digitalmar...@puremagic.com... > In case you didn't know, I have a set of unit test helper functions which > have > been being reviewed for possible inclusion in phobos. Here's an update. > > Most recent code: http://is.gd/F1OHat > > Okay. I took the previous suggestions into consideration and adjusted the > code a > bit more. However, most of the changes are to the documentation (though > there > are some changes to the code). Some of the code duplication was removed, > and the > way that some of the assertPred functions' errors are formatted has been > altered > so that values line up vertically, making them easier to compare. The big > change > is the docs though. There's now a fake version of assertPred at the top > with an > overall description for assertPred followed by the individual versions > with as > little documentation as seemed appropriate while still getting all of the > necessary information across. A couple of the functions still have > irritatingly > long example sections, but anything less wouldn't get the functionality > across. > > In any case. Here's the updated code. Review away. Andrei set the vote > deadline > for February 7th, at which point, if it passes majority vote, then it will > go > into Phobos. The number of functions is small enough now (thanks to having > consolidated most of them into the fantastically versatile assertPred) > that it > looks like it will likely go in std.exception if the vote passes rather > than > becoming a new module. So, the std.unittests title has now become a bit of > a > misnomer, but that's what I've been calling it, so it seemed appropriate > to > continue to label it that way in the thread's title. > Very nice! One minor change I'd suggest, for both readability and consistency: assertPred!"a == b"(1, 2); Current result: assertPred!"a == b" failed: [1] (a), [2] (b). Suggested result: assertPred!"a == b" failed: [1] (a) [2] (b) Or maybe even: assertPred!"a == b" failed: 1 == 2 [1] (a) [2] (b) Note the variable->value subsitution made on the original predicate string.
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittest block would have to be generated from the Examples section
in the
documentation, or you'd have to have some way to indicate that a
particular
unittest block got put into the documentation as an Examples section.
It's
certainly true that it would be ideal to have a way to avoid the
duplication,
but we don't have one at the moment, and it hasn't yet been a high
enough
priority to sort out how to do it and implement it.
I see. I understand that it does not have high priority. Just wondered
whether ...
Jens
The change is much simpler than what Jonathan suggests. A change can be
made such that any unittest preceded by a documentation comment is
automatically considered an example.
/**
Example:
*/
unittest
{
writeln("This is how it works.");
}
Andrei
BTW I consider this a very important topic. We have _plenty_ of examples
that don't work and are not mechanically verifiable. The reasons range
from minor typos to language changes to implementation limitations.
Generally this is what they call "documentation rot". This is terrible
PR for the language.
Changing ddoc to recognize documentation unittests would fix this matter
once and forever.
Last but not least, the "" separators for code samples are awful
because no editor recognizes them for anything - they confuse the hell
out of Emacs for one thing.
Andrei
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
Andrei Alexandrescu wrote:
> On 1/24/11 1:50 PM, Jens Mueller wrote:
> >Jonathan M Davis wrote:
> >>I think that it's been discussed a time or two, but nothing has been done
> >>about
> >>it. It wouldn't be entirely straightforward to do. Essentially, either a
> >>unittest block would have to be generated from the Examples section in the
> >>documentation, or you'd have to have some way to indicate that a particular
> >>unittest block got put into the documentation as an Examples section. It's
> >>certainly true that it would be ideal to have a way to avoid the
> >>duplication,
> >>but we don't have one at the moment, and it hasn't yet been a high enough
> >>priority to sort out how to do it and implement it.
> >
> >I see. I understand that it does not have high priority. Just wondered
> >whether ...
> >
> >Jens
>
> The change is much simpler than what Jonathan suggests. A change can
> be made such that any unittest preceded by a documentation comment
> is automatically considered an example.
>
> /**
> Example:
> */
> unittest
> {
> writeln("This is how it works.");
> }
That does not work for me.
$ dmd -unittest -D -Dftest.html test.d
I get an empty example.
void __unittest2();
Example:
Jens
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
done about
it. It wouldn't be entirely straightforward to do. Essentially,
either a
unittest block would have to be generated from the Examples section
in the
documentation, or you'd have to have some way to indicate that a
particular
unittest block got put into the documentation as an Examples section.
It's
certainly true that it would be ideal to have a way to avoid the
duplication,
but we don't have one at the moment, and it hasn't yet been a high
enough
priority to sort out how to do it and implement it.
I see. I understand that it does not have high priority. Just wondered
whether ...
Jens
The change is much simpler than what Jonathan suggests. A change can be
made such that any unittest preceded by a documentation comment is
automatically considered an example.
/**
Example:
*/
unittest
{
writeln("This is how it works.");
}
Andrei
BTW I consider this a very important topic. We have _plenty_ of examples
that don't work and are not mechanically verifiable. The reasons range
from minor typos to language changes to implementation limitations.
Generally this is what they call "documentation rot". This is terrible
PR for the language.
Changing ddoc to recognize documentation unittests would fix this matter
once and forever.
Last but not least, the "" separators for code samples are awful
because no editor recognizes them for anything - they confuse the hell
out of Emacs for one thing.
This only makes sense if:
1. The unit test immediately follows the item being documented
2. The unit test *only* tests that item.
The second one could be pretty annoying. Consider cases where several
functions interact (I've seen this many times on Microsoft's
Documentation), and it makes sense to make one example that covers all of
them. Having them 'testable' means creating several identical unit tests.
One way to easily fix this is to allow an additional parameter to the
comment:
/**
Example(Foo.foo(int), Foo.bar(int)):
*/
unittest
{
auto foo = new Foo;
foo.foo(5);
foo.bar(6);
assert(foo.toString() == "bazunga!");
}
The above means, copy the example to both Foo.foo(int) and Foo.bar(int)
An alternative that is more verbose, but probably more understandable:
/**
Example:
Covers Foo.foo(int)
Covers Foo.bar(int)
*/
Of course, a lack of target just means it applies to the item just
documented.
One other thing, using writefln is considered bad form in unit tests (you
want *no* output if the unit test works). But many examples might want to
demonstrate how e.g. an object interacts with writefln. Any suggestions?
The assert line above is not very pretty for example...
-Steve
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
Am 24.01.2011 21:39, schrieb Jens Mueller:
Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been done about
it. It wouldn't be entirely straightforward to do. Essentially, either a
unittest block would have to be generated from the Examples section in the
documentation, or you'd have to have some way to indicate that a particular
unittest block got put into the documentation as an Examples section. It's
certainly true that it would be ideal to have a way to avoid the duplication,
but we don't have one at the moment, and it hasn't yet been a high enough
priority to sort out how to do it and implement it.
I see. I understand that it does not have high priority. Just wondered
whether ...
Jens
The change is much simpler than what Jonathan suggests. A change can
be made such that any unittest preceded by a documentation comment
is automatically considered an example.
/**
Example:
*/
unittest
{
writeln("This is how it works.");
}
That does not work for me.
$ dmd -unittest -D -Dftest.html test.d
I get an empty example.
void__unittest2();
Example:
Jens
"A change can be made" - this is a proposal, not an implemented feature.
Re: const/immutable member functions
On Monday 24 January 2011 12:08:29 Don wrote: > Steven Schveighoffer wrote: > > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile > > > > wrote: > >> There are six, seven or more people that wish to do something about > >> this situation. TDPL is the D2 reference, but few little changes over > >> its first edition are acceptable if they improve the D language a > >> little. > >> > >> - Trass3r: asks if the code is ambiguous > >> - Jonathan M Davis: does't like it and puts const/etc on the right > >> - Simen kjaeraas thinks it's ambiguous though, and should be > >> disallowed, or at very least, discouraged. > >> - Jens Mueller: Preferred style is to write const on the right > >> - Andrej Mitrovic suggests to use @ but says it clutters up source code. > >> - I agree with Jonathan M Davis. > >> > >> What other people think about this situation? Do you want > >> const/immutable to be required on the right, or do you prefer the > >> current situation, or do you prefer some other solution? > > > > I wouldn't say that I *prefer* the current solution, but the current > > solution is not so bad that I need it changed. > > > > It works fine, despite being confusing. If it wasn't consistent with > > the rest of the attributes, I'd say it was in need of changes, but it > > fits within the scheme already outlined. > > It's a problem for all of the other attributes as well. I wish it were > disallowed for all of them. > Incidentally, putting it afterwards always works. Putting it before > doesn't always work, due to compiler bugs (for example, prefix 'pure' > doesn't work for inner functions). There there is a bug that attributes on constructors don't show up in generated .di files if they're on the right. I think that the real problem with putting them all on the right is that attributes such as static, public, and private are on the left in other languages, so it would be really weird to require that they be on the right. Still, it might be worth it. - Jonathan M Davis
ref param mismatch --> segfault
Hello,
I was defining a (generic & higher-order) list-of-terms parsing func. It uses
funcs which each parse a term of a given type from a token stream and advance a
ref index. As you may note below, I initially forgot to 'ref' the index in the
type of the parse func passed as param, in the generic func signature.
The compiler accepted and the program segfault-ed (for getting a value instead
of a reference, probably). Certainly ref qualifiers should be checked,
shouldn't they? The situation indeed is somewhat special here.
Foo getFoo(Token[] tokens, ref uint index)
{...}
Term[] getTerms (Term) (Term function (Token[], uint) parseFunc, Token[] tokens)
{...}
void main()
{
Foo[] foos = getTerms!(Foo)(&getFoo, s);# ==> segfault
}
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On Monday 24 January 2011 12:15:07 Andrei Alexandrescu wrote:
> On 1/24/11 1:50 PM, Jens Mueller wrote:
> > Jonathan M Davis wrote:
> >> I think that it's been discussed a time or two, but nothing has been
> >> done about it. It wouldn't be entirely straightforward to do.
> >> Essentially, either a unittest block would have to be generated from
> >> the Examples section in the documentation, or you'd have to have some
> >> way to indicate that a particular unittest block got put into the
> >> documentation as an Examples section. It's certainly true that it would
> >> be ideal to have a way to avoid the duplication, but we don't have one
> >> at the moment, and it hasn't yet been a high enough priority to sort
> >> out how to do it and implement it.
> >
> > I see. I understand that it does not have high priority. Just wondered
> > whether ...
> >
> > Jens
>
> The change is much simpler than what Jonathan suggests. A change can be
> made such that any unittest preceded by a documentation comment is
> automatically considered an example.
>
> /**
> Example:
> */
> unittest
> {
> writeln("This is how it works.");
> }
Well, I did say that either the documentation example had to be turned into a
unittest block or a unittest block had to be marked in some way to indicate
that
it should be turned into an example and then have it put into the documentation
that way. You're suggesting the latter of the two (which is probably the better
choice). I completely agree that this is an important topic. It's just that
it's
fallen by the wayside thus far.
Personally, I'm always having to copy-paste example back and forth between the
documentation and the unittest block in order to make sure that they're in
sync,
and even then I still screw up sometimes. So, I'd definitely like a solution
which makes it so that you don't have to duplicate the code/example like that.
- Jonathan M Davis
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
done about
it. It wouldn't be entirely straightforward to do. Essentially,
either a
unittest block would have to be generated from the Examples section
in the
documentation, or you'd have to have some way to indicate that a
particular
unittest block got put into the documentation as an Examples section.
It's
certainly true that it would be ideal to have a way to avoid the
duplication,
but we don't have one at the moment, and it hasn't yet been a high
enough
priority to sort out how to do it and implement it.
I see. I understand that it does not have high priority. Just wondered
whether ...
Jens
The change is much simpler than what Jonathan suggests. A change can be
made such that any unittest preceded by a documentation comment is
automatically considered an example.
/**
Example:
*/
unittest
{
writeln("This is how it works.");
}
Andrei
BTW I consider this a very important topic. We have _plenty_ of
examples that don't work and are not mechanically verifiable. The
reasons range from minor typos to language changes to implementation
limitations. Generally this is what they call "documentation rot".
This is terrible PR for the language.
Changing ddoc to recognize documentation unittests would fix this
matter once and forever.
Last but not least, the "" separators for code samples are awful
because no editor recognizes them for anything - they confuse the hell
out of Emacs for one thing.
This only makes sense if:
1. The unit test immediately follows the item being documented
2. The unit test *only* tests that item.
That's the what current examples do for virtually all of Phobos.
The second one could be pretty annoying. Consider cases where several
functions interact (I've seen this many times on Microsoft's
Documentation), and it makes sense to make one example that covers all
of them. Having them 'testable' means creating several identical unit
tests.
One way to easily fix this is to allow an additional parameter to the
comment:
/**
Example(Foo.foo(int), Foo.bar(int)):
*/
unittest
{
auto foo = new Foo;
foo.foo(5);
foo.bar(6);
assert(foo.toString() == "bazunga!");
}
The above means, copy the example to both Foo.foo(int) and Foo.bar(int)
Why would I force the reader to read the same example twice? And why
would I run the same unittest twice?
An alternative that is more verbose, but probably more understandable:
/**
Example:
Covers Foo.foo(int)
Covers Foo.bar(int)
*/
Of course, a lack of target just means it applies to the item just
documented.
I find documented unittests attractive mainly because they're _simple_.
As soon as we start to add that kind of stuff... exponential decay.
One other thing, using writefln is considered bad form in unit tests
(you want *no* output if the unit test works). But many examples might
want to demonstrate how e.g. an object interacts with writefln. Any
suggestions? The assert line above is not very pretty for example...
Yah, that is an issue. For examples that do non-unittesty stuff (e.g.
writeln, use sockets etc.) we can still use the old-style documentation.
By the way, for all examples that don't explicitly describe writeln, we
shouldn't use writeln anyway. Instead, we should use assert to clearly
describe what happens:
// BAD: example of concatenation
string s1 = "Hello, ";
string s2 = "world!";
writeln(s1 ~ s2); // writes Hello, world!
// GOOD: example of concatenation
string s1 = "Hello, ";
string s2 = "world!";
assert(s1 ~ s2 == "Hello, world!"); // no need for comment
Andrei
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want to put in the documentation. Sounds like a perfect
candidate for named unittests:
unittest(ddoc)
{
// outputted in documentation
}
Here "ddoc" would be a predefined identifier, kind of like X86 is for
version() statements.
unittest // our own complex unittest that we don't want to output in
the documentation
{
// ...
}
Re: ref param mismatch --> segfault
spir:
> Certainly ref qualifiers should be checked,
> shouldn't they? The situation indeed is somewhat special here.
>
> Foo getFoo(Token[] tokens, ref uint index)
> {...}
> Term[] getTerms (Term) (Term function (Token[], uint) parseFunc, Token[]
> tokens)
> {...}
> void main()
> {
> Foo[] foos = getTerms!(Foo)(&getFoo, s); # ==> segfault
> }
Please, create a very small but complete program that shows the problem :-) It
will go to Bugzilla.
Bye,
bearophile
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
"Andrei Alexandrescu" wrote in message
news:ihkpin$194m$1...@digitalmars.com...
> On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
>> The second one could be pretty annoying. Consider cases where several
>> functions interact (I've seen this many times on Microsoft's
>> Documentation), and it makes sense to make one example that covers all
>> of them. Having them 'testable' means creating several identical unit
>> tests.
>>
>> One way to easily fix this is to allow an additional parameter to the
>> comment:
>>
>> /**
>> Example(Foo.foo(int), Foo.bar(int)):
>> */
>> unittest
>> {
>> auto foo = new Foo;
>> foo.foo(5);
>> foo.bar(6);
>> assert(foo.toString() == "bazunga!");
>> }
>>
>> The above means, copy the example to both Foo.foo(int) and Foo.bar(int)
>
> Why would I force the reader to read the same example twice? And why would
> I run the same unittest twice?
>
Documentation is a reference, not a novel. If someone looked up the
documentation for "bar", why make them jump over to "foo" (and make sure
they know to do so) to see bar's examples?
Re: Showing unittest in documentation (Was Re: std.unittests[updated] for review)
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
> It's often the case that you want documentation examples to be short,
> but also correct. But you still want to write complex unittests that
> you don't want to put in the documentation. Sounds like a perfect
> candidate for named unittests:
>
> unittest(ddoc)
> {
> // outputted in documentation
> }
>
> Here "ddoc" would be a predefined identifier, kind of like X86 is for
> version() statements.
>
> unittest // our own complex unittest that we don't want to output in
> the documentation
> {
>// ...
> }
That also provides a good solution for unittests that belong in the examples
of more than one item:
unittest(foo, bar)
{
// Use both foo and bar
// outputted in documentation
}
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
Daniel Gibson wrote:
> Am 24.01.2011 21:39, schrieb Jens Mueller:
> >Andrei Alexandrescu wrote:
> >>On 1/24/11 1:50 PM, Jens Mueller wrote:
> >>>Jonathan M Davis wrote:
> I think that it's been discussed a time or two, but nothing has been done
> about
> it. It wouldn't be entirely straightforward to do. Essentially, either a
> unittest block would have to be generated from the Examples section in the
> documentation, or you'd have to have some way to indicate that a
> particular
> unittest block got put into the documentation as an Examples section. It's
> certainly true that it would be ideal to have a way to avoid the
> duplication,
> but we don't have one at the moment, and it hasn't yet been a high enough
> priority to sort out how to do it and implement it.
> >>>
> >>>I see. I understand that it does not have high priority. Just wondered
> >>>whether ...
> >>>
> >>>Jens
> >>
> >>The change is much simpler than what Jonathan suggests. A change can
> >>be made such that any unittest preceded by a documentation comment
> >>is automatically considered an example.
> >>
> >>/**
> >> Example:
> >>*/
> >>unittest
> >>{
> >> writeln("This is how it works.");
> >>}
> >
> >That does not work for me.
> >$ dmd -unittest -D -Dftest.html test.d
> >
> >I get an empty example.
> >void__unittest2();
> >
> >Example:
> >
> >
> >
> >
> >
> >Jens
>
> "A change can be made" - this is a proposal, not an implemented feature.
Stupid me. I was so excited that this may be possible that I didn't read
carefully.
Jens
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On 1/24/11 3:12 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:ihkpin$194m$1...@digitalmars.com...
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
The second one could be pretty annoying. Consider cases where several
functions interact (I've seen this many times on Microsoft's
Documentation), and it makes sense to make one example that covers all
of them. Having them 'testable' means creating several identical unit
tests.
One way to easily fix this is to allow an additional parameter to the
comment:
/**
Example(Foo.foo(int), Foo.bar(int)):
*/
unittest
{
auto foo = new Foo;
foo.foo(5);
foo.bar(6);
assert(foo.toString() == "bazunga!");
}
The above means, copy the example to both Foo.foo(int) and Foo.bar(int)
Why would I force the reader to read the same example twice? And why would
I run the same unittest twice?
Documentation is a reference, not a novel. If someone looked up the
documentation for "bar", why make them jump over to "foo" (and make sure
they know to do so) to see bar's examples?
Then there better are two examples, one focused on foo and the other on
bar. Anyway, I don't see the need for such a feature. All I want is to
have certain unittests appear in the generated documentation.
Andrei
Re: Showing unittest in documentation (Was Re: std.unittests[updated] for review)
On 1/24/11 3:16 PM, Nick Sabalausky wrote:
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want to put in the documentation. Sounds like a perfect
candidate for named unittests:
unittest(ddoc)
{
// outputted in documentation
}
Here "ddoc" would be a predefined identifier, kind of like X86 is for
version() statements.
unittest // our own complex unittest that we don't want to output in
the documentation
{
// ...
}
That also provides a good solution for unittests that belong in the examples
of more than one item:
unittest(foo, bar)
{
// Use both foo and bar
// outputted in documentation
}
Why make everything complicated? The simplest feature request becomes a
syntactic and semantic clusterfrak.
Andrei
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:37 PM, Steven Schveighoffer wrote:
On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
wrote:
On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
On 1/24/11 1:50 PM, Jens Mueller wrote:
Jonathan M Davis wrote:
I think that it's been discussed a time or two, but nothing has been
done about
it. It wouldn't be entirely straightforward to do. Essentially,
either a
unittest block would have to be generated from the Examples section
in the
documentation, or you'd have to have some way to indicate that a
particular
unittest block got put into the documentation as an Examples
section.
It's
certainly true that it would be ideal to have a way to avoid the
duplication,
but we don't have one at the moment, and it hasn't yet been a high
enough
priority to sort out how to do it and implement it.
I see. I understand that it does not have high priority. Just
wondered
whether ...
Jens
The change is much simpler than what Jonathan suggests. A change can
be
made such that any unittest preceded by a documentation comment is
automatically considered an example.
/**
Example:
*/
unittest
{
writeln("This is how it works.");
}
Andrei
BTW I consider this a very important topic. We have _plenty_ of
examples that don't work and are not mechanically verifiable. The
reasons range from minor typos to language changes to implementation
limitations. Generally this is what they call "documentation rot".
This is terrible PR for the language.
Changing ddoc to recognize documentation unittests would fix this
matter once and forever.
Last but not least, the "" separators for code samples are awful
because no editor recognizes them for anything - they confuse the hell
out of Emacs for one thing.
This only makes sense if:
1. The unit test immediately follows the item being documented
2. The unit test *only* tests that item.
That's the what current examples do for virtually all of Phobos.
#1 applies to all current examples, but I was also thinking of cases where
current unit tests may also be turned into examples.
The second in some cases is not true. Let's find an example in
std.algorithm:
http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html#partition
This example is very long and contains lots of std.algorithm functions
besides partition. With some slight tweaking, you could cleanly cover
multiple functions in one "Example". Such examples can be more
instructive because they are more like real code than two or three assert
tests.
The second one could be pretty annoying. Consider cases where several
functions interact (I've seen this many times on Microsoft's
Documentation), and it makes sense to make one example that covers all
of them. Having them 'testable' means creating several identical unit
tests.
One way to easily fix this is to allow an additional parameter to the
comment:
/**
Example(Foo.foo(int), Foo.bar(int)):
*/
unittest
{
auto foo = new Foo;
foo.foo(5);
foo.bar(6);
assert(foo.toString() == "bazunga!");
}
The above means, copy the example to both Foo.foo(int) and Foo.bar(int)
Why would I force the reader to read the same example twice? And why
would I run the same unittest twice?
Because you have a very illustrative example, and it applies to more than
one function. Why would you run it twice? Because your proposed system
*forces* you to run it twice.
An alternative that is more verbose, but probably more understandable:
/**
Example:
Covers Foo.foo(int)
Covers Foo.bar(int)
*/
Of course, a lack of target just means it applies to the item just
documented.
I find documented unittests attractive mainly because they're _simple_.
As soon as we start to add that kind of stuff... exponential decay.
It's only not simple if you want it to be. The /** Example: */ simple
method is also covered. Let's also not forget that the end result is
generated documentation, not the comments. All this 'non-simplicity' is
going to be hidden there.
The point is, not everyone writes *unique* examples for each of their
functions. I think a detailed example that demonstrates multiple
functions can be more informative than one that shows a simple usage.
This does not apply to all functions/types, and those functions would not
require "targeted" unit tests, just the simple ddoc designation.
One other thing, using writefln is considered bad form in unit tests
(you want *no* output if the unit test works). But many examples might
want to demonstrate how e.g. an object interacts with writefln. Any
suggestions? The assert line above is not very pretty for example...
Yah, that is an issue. For examples that do non-unittesty stuff (e.g.
writeln, use sockets etc.) we can still use the old-style documentation.
That sounds reasonable, although I still think we need to be able to
compile these to prevent doc rot.
By the way, for all examples that don't explicitly
Re: const/immutable member functions
Steven Schveighoffer: > I think we have more important problems to worry about than this. I agree. On the other hand in other languages I've seen that many small troubles pile up and reduce the enjoyment of using a language. Bye, bearophile
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On Mon, 24 Jan 2011 16:07:38 -0500, Andrej Mitrovic
wrote:
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want to put in the documentation. Sounds like a perfect
candidate for named unittests:
unittest(ddoc)
{
// outputted in documentation
}
Here "ddoc" would be a predefined identifier, kind of like X86 is for
version() statements.
unittest // our own complex unittest that we don't want to output in
the documentation
{
// ...
}
This would require a language change.
I like the ddoc comment version Andrei posted better.
-Steve
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On 1/24/11 3:36 PM, Steven Schveighoffer wrote: On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu wrote: I find documented unittests attractive mainly because they're _simple_. As soon as we start to add that kind of stuff... exponential decay. It's only not simple if you want it to be. The /** Example: */ simple method is also covered. Let's also not forget that the end result is generated documentation, not the comments. All this 'non-simplicity' is going to be hidden there. I think I worked too much with Walter because I'm almost thinking on his behalf. The thing is, at this point Walter (and me too) has a sympathy for language changes that remove undue limitations, and an aversion for language changes that introduce new stuff that the user would learn. So if we go to Walter with: "Hey, we can currently document a variety of declaration, but not unittests. Let's allow documenting unittests as well" he'd be like, "heh, that sounds great... okay". But if we go to him with "hey, here's this new feature that needs these syntactic additions and these semantics and and has several nontrivial effects and..." then the chance of adoptions are seriously harmed. Let's stick with KISS. Though I agree there are many improvements that can be brought to ddoc, I don't want a new feature, only to be able to document unittests. Andrei
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
Steven Schveighoffer wrote: If DIP9 is accepted (writeTo), then showing examples of how the format specifiers work would certainly look less confusing via writefln. I thought this was what std.format was for. -- Simen
Re: Showing unittest in documentation (Was Re: std.unittests[updated] for review)
On 01/25/2011 12:16 AM, Nick Sabalausky wrote:
"Andrej Mitrovic" wrote in message
news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
It's often the case that you want documentation examples to be short,
but also correct. But you still want to write complex unittests that
you don't want to put in the documentation. Sounds like a perfect
candidate for named unittests:
unittest(ddoc)
{
// outputted in documentation
}
Here "ddoc" would be a predefined identifier, kind of like X86 is for
version() statements.
unittest // our own complex unittest that we don't want to output in
the documentation
{
// ...
}
That also provides a good solution for unittests that belong in the examples
of more than one item:
unittest(foo, bar)
{
// Use both foo and bar
// outputted in documentation
}
...and now you need to also maintain annotation list in addition to
unittest body, and keep both in sync. Reminds me a
prototype-implementation idiom from some languages.
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On Mon, 24 Jan 2011 16:36:21 -0500, Steven Schveighoffer
wrote:
On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
wrote:
Yah, that is an issue. For examples that do non-unittesty stuff (e.g.
writeln, use sockets etc.) we can still use the old-style documentation.
That sounds reasonable, although I still think we need to be able to
compile these to prevent doc rot.
Something that might work (should be compiled during ddoc, right?)
/**
Example
*/
unittest
{
version(DDoc) // should not be outputted to example!
{
auto s = new Socket;
s.connect("192.168.50.5");
...
}
}
-Steve
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On Mon, 24 Jan 2011 16:43:39 -0500, Andrei Alexandrescu wrote: On 1/24/11 3:36 PM, Steven Schveighoffer wrote: On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu wrote: I find documented unittests attractive mainly because they're _simple_. As soon as we start to add that kind of stuff... exponential decay. It's only not simple if you want it to be. The /** Example: */ simple method is also covered. Let's also not forget that the end result is generated documentation, not the comments. All this 'non-simplicity' is going to be hidden there. I think I worked too much with Walter because I'm almost thinking on his behalf. The thing is, at this point Walter (and me too) has a sympathy for language changes that remove undue limitations, and an aversion for language changes that introduce new stuff that the user would learn. So if we go to Walter with: "Hey, we can currently document a variety of declaration, but not unittests. Let's allow documenting unittests as well" he'd be like, "heh, that sounds great... okay". But if we go to him with "hey, here's this new feature that needs these syntactic additions and these semantics and and has several nontrivial effects and..." then the chance of adoptions are seriously harmed. Let's stick with KISS. Though I agree there are many improvements that can be brought to ddoc, I don't want a new feature, only to be able to document unittests. My proposed enhancement is fully backwards-compatible, so it's no biggie if it's not in the first iteration. I was simply thinking in terms of my projects where I use unit tests to test several functions that interact with eachother, those would make nice examples. But I could only attach them to one function (or repeat them). -Steve
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
Andrei Alexandrescu wrote:
Documentation is a reference, not a novel. If someone looked up the
documentation for "bar", why make them jump over to "foo" (and make sure
they know to do so) to see bar's examples?
Then there better are two examples, one focused on foo and the other on
bar. Anyway, I don't see the need for such a feature. All I want is to
have certain unittests appear in the generated documentation.
Consider fopen and family - would you not say that an example like the
below is good enough for both fopen and fclose?
FILE* pFile;
pFile = fopen( "myfile.txt", "w" );
if ( pFile != null ) {
fputs ("fopen example",pFile);
fclose (pFile);
}
--
Simen
Re: const/immutable member functions
Jonathan M Davis wrote: > On Monday 24 January 2011 12:08:29 Don wrote: > > Steven Schveighoffer wrote: > > > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile > > > > > > wrote: > > >> There are six, seven or more people that wish to do something about > > >> this situation. TDPL is the D2 reference, but few little changes over > > >> its first edition are acceptable if they improve the D language a > > >> little. > > >> > > >> - Trass3r: asks if the code is ambiguous > > >> - Jonathan M Davis: does't like it and puts const/etc on the right > > >> - Simen kjaeraas thinks it's ambiguous though, and should be > > >> disallowed, or at very least, discouraged. > > >> - Jens Mueller: Preferred style is to write const on the right > > >> - Andrej Mitrovic suggests to use @ but says it clutters up source code. > > >> - I agree with Jonathan M Davis. > > >> > > >> What other people think about this situation? Do you want > > >> const/immutable to be required on the right, or do you prefer the > > >> current situation, or do you prefer some other solution? > > > > > > I wouldn't say that I *prefer* the current solution, but the current > > > solution is not so bad that I need it changed. > > > > > > It works fine, despite being confusing. If it wasn't consistent with > > > the rest of the attributes, I'd say it was in need of changes, but it > > > fits within the scheme already outlined. > > > > It's a problem for all of the other attributes as well. I wish it were > > disallowed for all of them. > > Incidentally, putting it afterwards always works. Putting it before > > doesn't always work, due to compiler bugs (for example, prefix 'pure' > > doesn't work for inner functions). > > There there is a bug that attributes on constructors don't show up in > generated > .di files if they're on the right. > > I think that the real problem with putting them all on the right is that > attributes such as static, public, and private are on the left in other > languages, so it would be really weird to require that they be on the right. > Still, it might be worth it. Can't one have only the type qualifiers on the right? I mean it's only confusing for those. pure/nothrow int foo(); causes no confusion at all. The access qualifiers also work fine in the beginning. On the right they won't even compile. Jens
Re: Showing unittest in documentation (Was Re: std.unittests[updated] for review)
On Monday, January 24, 2011 13:35:22 Andrei Alexandrescu wrote:
> On 1/24/11 3:16 PM, Nick Sabalausky wrote:
> > "Andrej Mitrovic" wrote in message
> > news:mailman.910.1295903266.4748.digitalmar...@puremagic.com...
> >
> >> It's often the case that you want documentation examples to be short,
> >> but also correct. But you still want to write complex unittests that
> >> you don't want to put in the documentation. Sounds like a perfect
> >> candidate for named unittests:
> >>
> >> unittest(ddoc)
> >> {
> >>
> >>// outputted in documentation
> >>
> >> }
> >>
> >> Here "ddoc" would be a predefined identifier, kind of like X86 is for
> >> version() statements.
> >>
> >> unittest // our own complex unittest that we don't want to output in
> >> the documentation
> >> {
> >>
> >> // ...
> >>
> >> }
> >
> > That also provides a good solution for unittests that belong in the
> > examples of more than one item:
> >
> > unittest(foo, bar)
> > {
> >
> >// Use both foo and bar
> >// outputted in documentation
> >
> > }
>
> Why make everything complicated? The simplest feature request becomes a
> syntactic and semantic clusterfrak.
I'm _very_ interested in having name unit tests, but I see no reason to
conflate
named unit tests and ddoc examples. I think that that would very quickly make
named unit tests far less useful than they would be otherwise - especially if
you go so far as to try and make the unittest block name have any connection to
the name of the function that the block is supposed to be the example fore.
Simply doing something like /++ Ditto +/ only now it's /++ Examples +/ or /++
Example +/ seems far better to me. There's no need to complicate things here or
conflate to separate concepts.
- Jonathan M Davis
Re: Is it true scope declarations are being removed?
Jonathan M Davis:
> Much of anything that requires code flow analysis doesn't tend to happen.
Right. You need (lot of) work to implement it, in a system language it can't be
fully accurate, and it may slow down compilation a little (Scala compiler is
powerful, but I don't think it's very fast).
But from using C lints I've seen that catching simple cases is better than
catching none of them, and in SafeD the code is less wild so probably a higher
percentage of cases can be caught.
Currently DMD catches only very simple errors:
class Foo {}
Foo foo() {
scope Foo f = new Foo;
return f; // test.d(4): Error: escaping reference to scope local f
}
Foo bar() {
scope Foo f = new Foo;
Foo f2 = f;
return f2; // no error here
}
void main() {}
Something similar happens with this little C program compiled with -Wall with
GCC:
int *foo() {
int a[5];
return a;
}
int *bar() {
int a[5];
int *p = a;
return p;
}
int main() {
return 0;
}
GCC warns only about the first function:
test.c: In function 'foo':
test.c:3:5: warning: function returns address of local variable
But a good C lint catches them both, statically (and the checking is very fast):
test.c 3 Warning 604: Returning address of auto variable 'a'
test.c 8 Warning 674: Returning address of auto through variable 'p'
Bye,
bearophile
Re: const/immutable member functions
2011/1/24 Simen kjaeraas :
> The suggestion is only for const alone on the left-hand side. const: and
> const{} would not be affected by such a change.
You're right, it's not confusing at all. It makes perfect sense for
function attributes to go on the right. But then I'd like all of them
to go there, like Jonathan suggested.
Torarin
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
Steven Schveighoffer napisał:
>> BTW I consider this a very important topic. We have _plenty_ of
>> examples that don't work and are not mechanically verifiable. The
>> reasons range from minor typos to language changes to implementation
>> limitations. Generally this is what they call "documentation rot".
>> This is terrible PR for the language.
>>
>> Changing ddoc to recognize documentation unittests would fix this
>> matter once and forever.
>>
>> Last but not least, the "" separators for code samples are awful
>> because no editor recognizes them for anything - they confuse the
>> hell out of Emacs for one thing.
>
> This only makes sense if:
>
> 1. The unit test immediately follows the item being documented 2. The
> unit test *only* tests that item.
>
> The second one could be pretty annoying. Consider cases where several
> functions interact (I've seen this many times on Microsoft's
> Documentation), and it makes sense to make one example that covers all
> of them. Having them 'testable' means creating several identical unit
> tests.
>
> One way to easily fix this is to allow an additional parameter to the
> comment:
>
> /**
> Example(Foo.foo(int), Foo.bar(int)):
> */
> unittest
> {
> auto foo = new Foo;
> foo.foo(5);
> foo.bar(6);
> assert(foo.toString() == "bazunga!");
> }
>
> The above means, copy the example to both Foo.foo(int) and
> Foo.bar(int)
>
> An alternative that is more verbose, but probably more understandable:
>
> /**
> Example:
> Covers Foo.foo(int)
> Covers Foo.bar(int)
> */
>
> Of course, a lack of target just means it applies to the item just
> documented.
Although coming from good intentions, it's just.. too much. The original
idea is very compelling without add-ons.
Often the interacting functions are members of the same class or at
least same module, so it's enough to place the unittest appropriately.
To cover remaining cases an artificial declaration may be introduced.
/// Uses of Foo.foo(int) and Foo.bar(int)
struct foo_and_bar_examples;
/// Example:
unittest { ... }
Both functions would simply link to the artificial symbol in their
ddocs.
> One other thing, using writefln is considered bad form in unit tests
> (you want *no* output if the unit test works). But many examples
> might want to demonstrate how e.g. an object interacts with
> writefln. Any suggestions? The assert line above is not very pretty
> for example...
I was thinking of mockFile.writefln(obj) but not sure if std.stdio can
handle it.
--
Tomek
Re: ref param mismatch --> segfault
On 01/24/2011 10:07 PM, bearophile wrote:
spir:
Certainly ref qualifiers should be checked,
shouldn't they? The situation indeed is somewhat special here.
Foo getFoo(Token[] tokens, ref uint index)
{...}
Term[] getTerms (Term) (Term function (Token[], uint) parseFunc, Token[] tokens)
{...}
void main()
{
Foo[] foos = getTerms!(Foo)(&getFoo, s); # ==> segfault
}
Please, create a very small but complete program that shows the problem :-) It
will go to Bugzilla.
Bye,
bearophile
I guess this does the job? (replaced token stream with plain stream, for the
example, thus it's really artificial since getFloat just does what parse!float
would do, but well... shows the bug).
float getFloat(string s, ref uint index) {
if (index >= s.length)
return -1;
float fl;
string[] ss = s[index..$].split();
string s0 = ss[0];
try
fl = to!float(s0);
catch (Exception _)
return -1;
index += s0.length;
return fl;
}
Term[] terms (Term) (Term function (string, uint) parseFunc, string s) {
Term[] terms = [];
Term term;
uint index = 0;
static enum SEP = ' ';
term = parseFunc(s, index);
if (term != -1) {
terms ~= term;
while (true) {
if (index >= s.length || s[index] != SEP)
break;
++ index;
term = parseFunc(s, index);
if (term == -1)
break;
terms ~= term;
}
}
return terms;
}
unittest {
string s = "3.33 1.0 2.2";
float[] floats = terms!(float)(&getFloat, s);
writeln(floats);
}
If you replace "uint" by "ref uint" in terms' signature, works fine.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On Mon, Jan 24, 2011 at 3:43 PM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
> On 1/24/11 3:36 PM, Steven Schveighoffer wrote:
>
>> On Mon, 24 Jan 2011 16:03:24 -0500, Andrei Alexandrescu
>> wrote:
>>
>>> I find documented unittests attractive mainly because they're
>>> _simple_. As soon as we start to add that kind of stuff... exponential
>>> decay.
>>>
>>
>> It's only not simple if you want it to be. The /** Example: */ simple
>> method is also covered. Let's also not forget that the end result is
>> generated documentation, not the comments. All this 'non-simplicity' is
>> going to be hidden there.
>>
>
> I think I worked too much with Walter because I'm almost thinking on his
> behalf. The thing is, at this point Walter (and me too) has a sympathy for
> language changes that remove undue limitations, and an aversion for language
> changes that introduce new stuff that the user would learn.
>
> So if we go to Walter with: "Hey, we can currently document a variety of
> declaration, but not unittests. Let's allow documenting unittests as well"
> he'd be like, "heh, that sounds great... okay". But if we go to him with
> "hey, here's this new feature that needs these syntactic additions and these
> semantics and and has several nontrivial effects and..." then the chance of
> adoptions are seriously harmed.
>
> Let's stick with KISS. Though I agree there are many improvements that can
> be brought to ddoc, I don't want a new feature, only to be able to document
> unittests.
Here's another approach:
When you think about it, what we're after is tagging unit tests as code
examples, so why not do exactly that with annotations?
@example(Foo.bar)
unittest {
//...
}
It means there are no new keywords to worry about, and this feels more like
a job for metadata than a language feature to me. We'd probably have to
formalize adding parameters to annotations, but that's pretty much
inevitable if they're ever going to reach a useful state.
Re: const/immutable member functions
Don Wrote:
> Steven Schveighoffer wrote:
> > On Mon, 24 Jan 2011 13:36:36 -0500, bearophile
> > wrote:
> >
> >> There are six, seven or more people that wish to do something about
> >> this situation. TDPL is the D2 reference, but few little changes over
> >> its first edition are acceptable if they improve the D language a little.
> >>
> >> - Trass3r: asks if the code is ambiguous
> >> - Jonathan M Davis: does't like it and puts const/etc on the right
> >> - Simen kjaeraas thinks it's ambiguous though, and should be
> >> disallowed, or at very least, discouraged.
> >> - Jens Mueller: Preferred style is to write const on the right
> >> - Andrej Mitrovic suggests to use @ but says it clutters up source code.
> >> - I agree with Jonathan M Davis.
> >>
> >> What other people think about this situation? Do you want
> >> const/immutable to be required on the right, or do you prefer the
> >> current situation, or do you prefer some other solution?
> >
> > I wouldn't say that I *prefer* the current solution, but the current
> > solution is not so bad that I need it changed.
> >
> > It works fine, despite being confusing. If it wasn't consistent with
> > the rest of the attributes, I'd say it was in need of changes, but it
> > fits within the scheme already outlined.
>
> It's a problem for all of the other attributes as well. I wish it were
> disallowed for all of them.
> Incidentally, putting it afterward always works. Putting it before
> doesn't always work, due to compiler bugs (for example, prefix 'pure'
> doesn't work for inner functions).
This "problem" happens because D belongs to the C-family of languages which
puts the return type _before_ the function name.
Languages that don't follow this syntactic convention (some would call it a
mistake) have it very consistent and readable:
attribute funcName inputParams -> outputParams { body }
This is the typical functional language design.
Of course I'm not suggesting to apply such a huge change to D but if I were to
design a brand new language than I would put the return type at the end.
I feel that putting function attributes at the end increases this IMHO bad
design which boils down to a right-to-left programming language.
I'm a native Hebrew speaker and it looks weird to me, so I can't imagine how it
could look right to any left-to-right language native speaker...
Re: Showing unittest in documentation (Was Re: std.unittests [updated] for review)
On 01/24/2011 10:03 PM, Andrei Alexandrescu wrote:
One other thing, using writefln is considered bad form in unit tests
(you want *no* output if the unit test works). But many examples might
want to demonstrate how e.g. an object interacts with writefln. Any
suggestions? The assert line above is not very pretty for example...
Yah, that is an issue. For examples that do non-unittesty stuff (e.g. writeln,
use sockets etc.) we can still use the old-style documentation. By the way, for
all examples that don't explicitly describe writeln, we shouldn't use writeln
anyway. Instead, we should use assert to clearly describe what happens:
// BAD: example of concatenation
string s1 = "Hello, ";
string s2 = "world!";
writeln(s1 ~ s2); // writes Hello, world!
// GOOD: example of concatenation
string s1 = "Hello, ";
string s2 = "world!";
assert(s1 ~ s2 == "Hello, world!"); // no need for comment
This is a very good example.
It seems that in the D style, and in Phobos use, unittests are only considered
for maintenance. (What is sometimes called regression test suites:
http://en.wikipedia.org/wiki/Regression_testing).
Many programmers instead use test funcs to provide feedback on how pieces of
code work during development. Even when it does not bug. I for one constantly
run tests. Using the example above, my initial test func would be eg:
string s1 = "Hello, ";
string s2 = "world!";
writefln("%s ~ %s --> %s", s1,s2, s1 ~ s2);
This goes well with "exploratory programming". To setup things correctly, I
need much information on all aspects of the part of code I'm currently dealing
with, including object internal state, for instance (toString is vital, often
defined before anything else). Data on what works fine also helps in fixing
what doesn't.
Then, when all work fine, I would comment out writelfn and replace it with an
assert. But I keep it so that in case of later bug introduced by changes, code
is still there to provide all necessary information to diagnose. (Hope I'm clear.)
Such verbose test suite, when done right, is also a 'show' of all kinds of
functionality a module is able to provide, at best with self-explaining output.
Now, for sure assert and write* are somewhat redondant for testing. What I
dream of is a testing func similar to assert() but that writes info out even on
success; then a silent mode would switch that off and write only on failure.
Would be easier if this func takes 2 params, eg:
check(expression, expectation);
writes out on success:
expression --> to!string(expectation)
writes out on failure:
** test error **
expression : (expression)
expectation : to!string(expectation)
outcome : to!string(outcome)
This would also avoid having a separate testing func for cases where
expectation is an exception.
Denis
--
_
vita es estrany
spir.wikidot.com
Re: const/immutable member functions
This "problem" happens because D belongs to the C-family of languages which puts the return type _before_ the function name. It has nothing to do with being a C-family language. C/C++ don't have this, and the rules are perfectly clear. It is just unifying two or more unrelated things in one syntax for the sake of consistency (and compiler complexity?).
Re: ref param mismatch --> segfault
spir:
> I guess this does the job?
It's not minimal and it's not complete, it misses a main and the imports :-)
But it's OK.
A reduced test case shows that DMD has holes here, this compiles with no
errors. I think this DMD bug is already in Bugzilla:
void foo(ref int x) {}
void bar1(void function(int) f) {}
void bar2(void function(string) f) {}
void main() {
bar1(&foo);
bar2(&foo);
}
Bye,
bearophile
Re: const/immutable member functions
On 01/24/2011 07:36 PM, bearophile wrote: What other people think about this situation? Do you want const/immutable to be required on the right, or do you prefer the current situation, or do you prefer some other solution? Comparing with C-like typing syntax that, I guess, are planned for deprecation: C typing is not wrong, ambiguous, just arguably more difficult to decode, and unnecessary because we have a better alternative. IIUC, prefixed const and the like instead are not only unnecessary, but inherently ambiguous. Denis -- _ vita es estrany spir.wikidot.com
Re: const/immutable member functions
2011/1/24 foobar :
> This "problem" happens because D belongs to the C-family of languages which
> puts the return type _before_ the function name.
>
> Languages that don't follow this syntactic convention (some would call it a
> mistake) have it very consistent and readable:
> attribute funcName inputParams -> outputParams { body }
> This is the typical functional language design.
It is arguably more consistent to have the return type come first, as
in variable declarations:
int a = 4;
int foo() { return 5; }
Both "foo()" and "a" are now of type int.
Torarin
Re: std.unittests [updated] for review
Dnia 2011-01-24, o godz. 06:34:49
Jonathan M Davis napisał(a):
> In case you didn't know, I have a set of unit test helper functions which
> have
> been being reviewed for possible inclusion in phobos. Here's an update.
>
> Most recent code: http://is.gd/F1OHat
>
> Okay. I took the previous suggestions into consideration and adjusted the
> code a
> bit more. However, most of the changes are to the documentation (though there
> are some changes to the code). Some of the code duplication was removed, and
> the
> way that some of the assertPred functions' errors are formatted has been
> altered
> so that values line up vertically, making them easier to compare.
That's a solid improvement, thanks.
> The big change
> is the docs though. There's now a fake version of assertPred at the top with
> an
> overall description for assertPred followed by the individual versions with
> as
> little documentation as seemed appropriate while still getting all of the
> necessary information across. A couple of the functions still have
> irritatingly
> long example sections, but anything less wouldn't get the functionality
> across.
I'm not sure...
Examples:
assertPred!"+"(7, 5, 12);
assertPred!"-"(7, 5, 2);
assertPred!"*"(7, 5, 35);
assertPred!"/"(7, 5, 1);
assertPred!"%"(7, 5, 2);
assertPred!"^^"(7, 5, 16_807);
assertPred!"&"(7, 5, 5);
assertPred!"|"(7, 5, 7);
assertPred!"^"(7, 5, 2);
assertPred!"<<"(7, 1, 14);
assertPred!">>"(7, 1, 3);
assertPred!">>>"(-7, 1, 2_147_483_644);
assertPred!"~"("hello ", "world", "hello world");
assert(collectExceptionMsg(assertPred!"+"(7, 5, 11)) ==
"assertPred!\"+\" failed: [7] + [5]:\n" ~
"[12] (actual)\n" ~
"[11] (expected).");
assert(collectExceptionMsg(assertPred!"/"(11, 2, 6, "It failed!")) ==
"assertPred!\"/\" failed: [11] / [2]:\n" ~
"[5] (actual)\n" ~
"[6] (expected): It failed!");
Picking only one or two from the above would be enough to "get it". It's the
description that ought to explain the function's behavior in all cases,
examples are for jump-starting the user to action.
Oh, one more thing. Previously you asked me why a generic collectThrown is
useful and I forgot to answer. One use is the same as collectExceptionMsg()
without being tied to the msg property.
auto e = collectThrown!MyException(expr);
assert(e);
assert(e.errorCode == expectedCode);
assert(cast(MyCauseException) e.next);
I'm not proposing to yank collectExceptionMsg or assertThrown in favor of
collectThrown, they're useful idioms. But having also collectThrown (a generic
replacement for existing collectException) would definitely be of value.
> In any case. Here's the updated code. Review away. Andrei set the vote
> deadline
> for February 7th, at which point, if it passes majority vote, then it will go
> into Phobos. The number of functions is small enough now (thanks to having
> consolidated most of them into the fantastically versatile assertPred) that
> it
> looks like it will likely go in std.exception if the vote passes rather than
> becoming a new module. So, the std.unittests title has now become a bit of a
> misnomer, but that's what I've been calling it, so it seemed appropriate to
> continue to label it that way in the thread's title.
Good luck!
--
Tomek
Re: ref param mismatch --> segfault
"bearophile" wrote in message
news:ihl0i0$1mes$1...@digitalmars.com...
> spir:
>
> A reduced test case shows that DMD has holes here, this compiles with no
> errors. I think this DMD bug is already in Bugzilla:
>
> void foo(ref int x) {}
> void bar1(void function(int) f) {}
> void bar2(void function(string) f) {}
> void main() {
>bar1(&foo);
>bar2(&foo);
> }
>
Good old http://d.puremagic.com/issues/show_bug.cgi?id=3797
Re: Showing unittest in documentation (Was Re: std.unittests
Steven Schveighoffer Wrote:
> On Mon, 24 Jan 2011 15:20:13 -0500, Andrei Alexandrescu
> wrote:
>
> > On 1/24/11 2:15 PM, Andrei Alexandrescu wrote:
> >> On 1/24/11 1:50 PM, Jens Mueller wrote:
> >>> Jonathan M Davis wrote:
> I think that it's been discussed a time or two, but nothing has been
> done about
> it. It wouldn't be entirely straightforward to do. Essentially,
> either a
> unittest block would have to be generated from the Examples section
> in the
> documentation, or you'd have to have some way to indicate that a
> particular
> unittest block got put into the documentation as an Examples section.
> It's
> certainly true that it would be ideal to have a way to avoid the
> duplication,
> but we don't have one at the moment, and it hasn't yet been a high
> enough
> priority to sort out how to do it and implement it.
> >>>
> >>> I see. I understand that it does not have high priority. Just wondered
> >>> whether ...
> >>>
> >>> Jens
> >>
> >> The change is much simpler than what Jonathan suggests. A change can be
> >> made such that any unittest preceded by a documentation comment is
> >> automatically considered an example.
> >>
> >> /**
> >> Example:
> >> */
> >> unittest
> >> {
> >> writeln("This is how it works.");
> >> }
> >>
> >>
> >> Andrei
> >
> > BTW I consider this a very important topic. We have _plenty_ of examples
> > that don't work and are not mechanically verifiable. The reasons range
> > from minor typos to language changes to implementation limitations.
> > Generally this is what they call "documentation rot". This is terrible
> > PR for the language.
> >
> > Changing ddoc to recognize documentation unittests would fix this matter
> > once and forever.
> >
> > Last but not least, the "" separators for code samples are awful
> > because no editor recognizes them for anything - they confuse the hell
> > out of Emacs for one thing.
>
> This only makes sense if:
>
> 1. The unit test immediately follows the item being documented
> 2. The unit test *only* tests that item.
>
> The second one could be pretty annoying. Consider cases where several
> functions interact (I've seen this many times on Microsoft's
> Documentation), and it makes sense to make one example that covers all of
> them. Having them 'testable' means creating several identical unit tests.
>
> One way to easily fix this is to allow an additional parameter to the
> comment:
>
> /**
> Example(Foo.foo(int), Foo.bar(int)):
> */
> unittest
> {
> auto foo = new Foo;
> foo.foo(5);
> foo.bar(6);
> assert(foo.toString() == "bazunga!");
> }
>
> The above means, copy the example to both Foo.foo(int) and Foo.bar(int)
>
> An alternative that is more verbose, but probably more understandable:
>
> /**
> Example:
> Covers Foo.foo(int)
> Covers Foo.bar(int)
> */
>
> Of course, a lack of target just means it applies to the item just
> documented.
>
> One other thing, using writefln is considered bad form in unit tests (you
> want *no* output if the unit test works). But many examples might want to
> demonstrate how e.g. an object interacts with writefln. Any suggestions?
> The assert line above is not very pretty for example...
>
> -Steve
Unit-tests are defined on a module level, not a function level, hence I would
expect to see the unit-tests that serve as examples to appear in an examples
section on the page the documents the module itself. In the online docs I would
expect the function names used in the example to be links to the individual
function doc and for each function have a list of links to examples it
participated in.
This should be automatic and the user shouldn't need to provide the "list of
functions documented in this example".
Just my two cents..
Re: const/immutable member functions
foobar: > This "problem" happens because D belongs to the C-family of languages which > puts the return type _before_ the function name. Of course C++ has everything :-) See the trailing-return-type feature of C++0x: http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x Bye, bearophile
Re: const/immutable member functions
so Wrote: > > This "problem" happens because D belongs to the C-family of languages > > which puts the return type _before_ the function name. > > It has nothing to do with being a C-family language. C/C++ don't have > this, and the rules are perfectly clear. > It is just unifying two or more unrelated things in one syntax for the > sake of consistency (and compiler complexity?). C++ style aka Yoda style: 1. public double func(int input) const; 2. const double func(int input); 3. const double func(int input) const; VS. hypothetical left-to-right style: 1. public const func (int input) -> (double); 2. func (int input) -> (const double); 3. const func (int input) -> (const double); Which ordering makes for a more natural read?
Re: const/immutable member functions
C++ style aka Yoda style: 1. public double func(int input) const; 2. const double func(int input); 3. const double func(int input) const; VS. hypothetical left-to-right style: 1. public const func (int input) -> (double); 2. func (int input) -> (const double); 3. const func (int input) -> (const double); Which ordering makes for a more natural read? For you or for me? :)
Re: const/immutable member functions
bearophile Wrote: > foobar: > > > This "problem" happens because D belongs to the C-family of languages which > > puts the return type _before_ the function name. > > Of course C++ has everything :-) See the trailing-return-type feature of > C++0x: > http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax > http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x > > Bye, > bearophile Of course they added it, they also experienced similar problems with the current syntax since it is out of place in the reading order.
Re: const/immutable member functions
so Wrote: > > C++ style aka Yoda style: > > 1. public double func(int input) const; > > 2. const double func(int input); > > 3. const double func(int input) const; > > > > VS. > > hypothetical left-to-right style: > > 1. public const func (int input) -> (double); > > 2. func (int input) -> (const double); > > 3. const func (int input) -> (const double); > > > > Which ordering makes for a more natural read? > > For you or for me? :) Look at this from a "It reads like English" prospective and not from a "I'm an experienced c++ programmer and therefore already used to this crap" perspective. In other words, if you were just starting to learn your first programming language, what would confuse you less?
Re: const/immutable member functions
Of course C++ has everything :-) See the trailing-return-type feature of C++0x: http://en.wikipedia.org/wiki/C%2B%2B0x#Alternative_function_syntax http://stackoverflow.com/questions/4523617/omit-return-type-in-c0x Bye, bearophile Now i am completely lost, i can't see any connection at all!
Re: const/immutable member functions
Look at this from a "It reads like English" prospective and not from a "I'm an experienced c++ programmer and therefore already used to this crap" perspective. In other words, if you were just starting to learn your first programming language, what would confuse you less? If i was starting to learn a language, everything would confuse me. I know C rules, i learned it with zero hostility to any other language, it is perfectly natural to me. Ok you said your natural language is not English, how is that you still speak it, could be because you just learned its basics? Which one is the Yoda now? Hebrew or English? Which one is natural? Or i should ask which one is natural for "you"?
