Hi, I'm also working on postgresql client implementation and common DB
interface (in my spare time between other projects). It's using native
postgres protocol without using libpq. Tt also supports binary
formatting of row fields - that should outperform textual libraries (no
parsing/toString).
D.org or whatever? Do tell! This is news (to me anyway).
On Monday 24 January 2011 15:27:08 foobar wrote:
> 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
On Monday 24 January 2011 13:52:49 Jens Mueller wrote:
> 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
Nick wrote:
> You should stick this in the announcements group.
Yeah, I'm still working some kinks out though. (Trial by fire - I
ended up pushing the *new* mysql module to the live work server in
an unrelated update yesterday! So now frantically fixing things
for tonight's launches...
The breaka
"Adam D. Ruppe" wrote in message
news:ihhsv0$1fgf$1...@digitalmars.com...
> alias DataObjectFromSqlCreateTable!(import("db.sql"), "users") User;
> // sql source code , table to fetch
>
> void main() {
>auto obj = new User(null); // that null should actually be
Also, you can't do this in C++.
Which was my point.
Argh, hate it that you can't edit posts, ignore the second line.
C++ style aka Yoda style:
1. public double func(int input) const;
Also, you can't do this in C++.
Which was my point.
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
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!
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
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#Alte
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
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
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://stack
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
"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 func
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 s
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
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 dep
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 funct
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 s
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
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
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_.
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)
{...}
voi
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 "documentat
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 th
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).
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,
>
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 referenc
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 stuf
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. Any
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 rea
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
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
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.
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
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
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
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
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 Micr
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 str
"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 li
"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 make
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[]
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 "ddo
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
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
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 gen
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
> >> it
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
unittes
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 straight
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 g
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
"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/F1OH
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
docu
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
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 outl
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 r
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
> >
>
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.
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
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
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
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
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
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 adjuste
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.
===
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
>
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 Subve
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 curr
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
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
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 asse
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 pla
On 1/24/11, Steven Schveighoffer wrote:
> That wasn't done by the compiler anyways.
>
> -Steve
>
Yeah I've noticed that. Lazy DMD compiler! :)
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, laz
== 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, d
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=207
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
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 suggestio
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
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 con
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 i
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.
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
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 func
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
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
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,
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
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 ty
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"?
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 e
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
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 mi
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?
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
* dec
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 fea
1 - 100 of 108 matches
Mail list logo
