Jacob Carlborg Wrote:
> On 2011-02-10 20:15, Walter Bright wrote:
> > Nick Sabalausky wrote:
> >> "bearophile" wrote in message
> >> news:iivb5n$na3$1...@digitalmars.com...
> >>> auto x;
> >>> if (localtime().hours >= 8) {
> >>> x = "awake!"
> >>> } else {
> >>> x = "asleep, go away."
> >>> }
> >
On 2/10/2011 11:14 PM, so wrote:
> On Fri, 11 Feb 2011 08:56:07 +0200, Brad Roberts wrote:
>
>> On 2/10/2011 10:53 PM, so wrote:
While in isolation that's a good idea, how far should it be taken? Should
the compiler emit information on which
variables wound up in which registers,
On Fri, 11 Feb 2011 08:56:07 +0200, Brad Roberts
wrote:
On 2/10/2011 10:53 PM, so wrote:
While in isolation that's a good idea, how far should it be taken?
Should the compiler emit information on which
variables wound up in which registers, and why? What about other of
the myriad of compi
On 2/10/2011 10:53 PM, so wrote:
>> While in isolation that's a good idea, how far should it be taken? Should
>> the compiler emit information on which
>> variables wound up in which registers, and why? What about other of the
>> myriad of compiler optimizations?
>
> Isn't Inlining by far the mo
While in isolation that's a good idea, how far should it be taken?
Should the compiler emit information on which variables wound up in
which registers, and why? What about other of the myriad of compiler
optimizations?
Isn't Inlining by far the most important (most practical) optimization
On Thursday 10 February 2011 22:35:34 Walter Bright wrote:
> Stewart Gordon wrote:
> > On 09/02/2011 12:14, spir wrote:
> >> Hello,
> >>
> >> Walter states that inline annotations are useless, since programmers
> >> cannot generally know
> >> which function /should/ be inlined --depending on a var
You cannot force inlining in C(++) either. The inline keyword is only a
suggestion.
I'm not understanding your last comment that a .lib would be required.
That's not correct, as since you're supplying the full source anyway
(needed for inlining), just compile in that source from the command
Stewart Gordon wrote:
On 09/02/2011 12:14, spir wrote:
Hello,
Walter states that inline annotations are useless, since programmers
cannot generally know
which function /should/ be inlined --depending on a variety of
factors, inlining may in
fact be counter-productive.
I hate not being abl
spir wrote:
Thus, at best, we would need to know a bit about criteria used by the
compiler for deciding whether to inline or not; provided a doc
explaining this is at all readable by people who do not have the
compiler-writer gene.
Aside that, let us imagine an inline annotation beeing, not a r
On Thursday 10 February 2011 21:50:45 so wrote:
> > We _must_ have it there, so anyone overriding those functions _must_
> > use it for those functions. They could create non-const versions in
> > addition to
> > the const ones,
>
> It is the whole point, they can't.
Hmm. You're right (I just tri
We _must_ have it there, so anyone overriding those functions _must_
use it for those functions. They could create non-const versions in
addition to
the const ones,
It is the whole point, they can't.
but they _must_ create the const versions. They're stuck.
There's no way around it without b
Vote++
--
Graham St Jack
This isn't really true. If you make opEquals const, then anything
opEquals calls must be const. Inevitably, you need to make a lot of
your object const, which then goes viral to things that object uses, etc.
On the other hand, I don't think opt-in const is that worthy a goal.
Things that
"Andrej Mitrovic" wrote in message
news:mailman.1477.1297394949.4748.digitalmar...@puremagic.com...
> On 2/11/11, Nick Sabalausky wrote:
>> "Andrej Mitrovic" wrote in message
>> news:mailman.1476.1297391467.4748.digitalmar...@puremagic.com...
>>> What the hell does "to!" have to do with anythin
On 2/11/11, Nick Sabalausky wrote:
> "Andrej Mitrovic" wrote in message
> news:mailman.1476.1297391467.4748.digitalmar...@puremagic.com...
>> What the hell does "to!" have to do with anything. Disregard my last
>> post, it's obviously 3 AM and I'm talking gibberish.
>>
>
> I just meant that "iota
"Andrej Mitrovic" wrote in message
news:mailman.1476.1297391467.4748.digitalmar...@puremagic.com...
> What the hell does "to!" have to do with anything. Disregard my last
> post, it's obviously 3 AM and I'm talking gibberish.
>
I just meant that "iota" looks a lot like (spaces added for clarity)
"Bruno Medeiros" wrote in message
news:ij1guf$694$1...@digitalmars.com...
> You guys are way on the wrong track here.
>
> I'm very much a fan of simple and orthogonal languages. But this statement
> has a big problem: it's not clear what one actually considers to be
> "simple" and "orthogonal".
> To avoid troubles in generic code you need a little workaround:
> if (__traits(isUnsigned, x) || x >= 0) { ...
That's not good enough yet. The first part of the test needs to be done in a
static if.
Bye,
bearophile
> Do you like this little change in the D2 language?
To avoid troubles in generic code you need a little workaround:
if (__traits(isUnsigned, x) || x >= 0) { ...
Bye,
bearophile
What the hell does "to!" have to do with anything. Disregard my last
post, it's obviously 3 AM and I'm talking gibberish.
In any case,
alias iota range;
Problem solved for me!
Google search takes your preferences into account. They must be tracking
your search history, peeking into your gmail accounts etc.
I sooo hate that, it kills the very meaning of searching!
Make to! smarter?
auto someRange = to!range(0, 5);
Here's python:
>>> range(5, 10)
[5, 6, 7, 8, 9]
>>> range(0, 10, 3)
[0, 3, 6, 9]
>>> range(-10, -100, -30)
[-10, -40, -70]
And D would be:
to!range(5, 10);
to!range(5, 10, 3);
to!range(-1, -100, -30);
But abusing the range word might be bad. I
On Thursday, February 10, 2011 17:45:21 Nick Sabalausky wrote:
> "Andrei Alexandrescu" wrote in message
> news:ij1nkf$i7g$2...@digitalmars.com...
>
> > I don't find the name "iota" stupid.
>
> Far as I can tell, you seem to be nearly the only one who finds it to be a
> good name. I can live with
"Andrei Alexandrescu" wrote in message
news:ij1nkf$i7g$2...@digitalmars.com...
>
> I don't find the name "iota" stupid.
>
Far as I can tell, you seem to be nearly the only one who finds it to be a
good name. I can live with it, since I've just simply learned that in D
"iota(x,y)" means "range
"Max Samukha" wrote in message
news:ij10n7$25p0$1...@digitalmars.com...
> On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
>> On 2/10/11 12:30 AM, Olivier Pisano wrote:
>>> Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
> - There is no need to learn to
On 02/11/2011 12:20 AM, Don wrote:
I don't like this idea at all. If the problem is that it's too easy to hide
the underlying function without noticing (no compile-time error), then fix
how the language treats hidden functions (make it a compile-time error). If
opEquals has this problem, other no
Recently I have shown some bugs (and added few enhancement requests):
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=129069
Among those there is my suggestion to statically disallow unsigned<0
comparisons:
http://d.puremagic.com/issues/show_bug.cgi?id=5539
So
On 02/10/2011 11:50 PM, Jesse Phillips wrote:
spir Wrote:
Use "Interval". Actually better than range, because it's an international word
(thus far easier for non-native English speakers). English very often provides
2 words (typically one is germanic, the other imported); choose the
internation
Andrei Alexandrescu Wrote:
>
> I don't find the name "iota" stupid.
I never entirely understood the name choice. I suppose "iota" could be related
to a "small step" so iota(1,5) is a series of small steps from 1 to 5?
Michel Fortin wrote:
On 2011-02-10 15:22:48 -0500, Don said:
Steven Schveighoffer wrote:
This doesn't work. If you only define one, then you will have
problems with hidden function errors, and/or inconsistencies. For
example, how does .opEquals(Object obj1, Object obj2) know which
version
spir Wrote:
> Use "Interval". Actually better than range, because it's an international
> word
> (thus far easier for non-native English speakers). English very often
> provides
> 2 words (typically one is germanic, the other imported); choose the
> international one when none is obviously be
On Thu, 10 Feb 2011 16:34:57 -0500, Don wrote:
Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 15:22:48 -0500, Don wrote:
A tiny compromise which could be made, is to silently add 'const' to
any class opEquals declaration, even if not present in the source.
That way, simple use cases wou
Has it been considered for constness or such constraints not to be
inherited? (Rather plain functype signature.)
Denis
I asked something similar not more than a week ago,
it is possible in theory i think but implementation is very problematic
and requires a big shift in the meaning of const
On 2/10/11 9:47 AM, spir wrote:
On 02/10/2011 04:34 PM, Max Samukha wrote:
On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
On 2/10/11 12:30 AM, Olivier Pisano wrote:
Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a functi
On 2/10/11 9:49 AM, Ary Manzana wrote:
On 2/10/11 12:34 PM, Max Samukha wrote:
On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
On 2/10/11 12:30 AM, Olivier Pisano wrote:
Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a fu
On 2011-02-10 15:22:48 -0500, Don said:
Steven Schveighoffer wrote:
This doesn't work. If you only define one, then you will have problems
with hidden function errors, and/or inconsistencies. For example, how
does .opEquals(Object obj1, Object obj2) know which version to call?
I think the
On 2/10/11 9:33 AM, Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
wrote:
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to cod
Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 15:22:48 -0500, Don wrote:
A tiny compromise which could be made, is to silently add 'const' to
any class opEquals declaration, even if not present in the source.
That way, simple use cases would still compile without complaint.
(As long as only
2011/2/10 Bruno Medeiros :
> I'm very much a fan of simple and orthogonal languages. But this statement
> has a big problem: it's not clear what one actually considers to be "simple"
> and "orthogonal". What people consider to be orthogonal can vary not only a
> little, but actually a lot. Sometime
%u Wrote:
> What Phobos modules are currently depreciated or undergoing mayor
> changes right now? And what are their replacements if any?
>
> I suppose std.xml is one. What about std.regex/std.regexp,
> std.stream/std.stdio/std.cstream/std.socketstream, std.bind,
> std.boxer/std.variant?
>
> BT
On Thursday 10 February 2011 12:22:48 Don wrote:
> Steven Schveighoffer wrote:
> > On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
> >
> > wrote:
> >> On 2/10/11 2:58 AM, Peter Alexander wrote:
> >>> On 10/02/11 8:19 AM, Don wrote:
> Andrei once stated a worthy goal: as far as possib
On 03/02/2011 01:48, Simen kjaeraas wrote:
Jonathan M Davis wrote:
On Wednesday, February 02, 2011 16:16:00 Andrej Mitrovic wrote:
On 2/3/11, Jonathan M Davis wrote:
> Usually the thing to do would be to either comment them out or put an
> assert(0)
Can't do that with classes and struct.
On Thu, 10 Feb 2011 15:22:48 -0500, Don wrote:
A tiny compromise which could be made, is to silently add 'const' to any
class opEquals declaration, even if not present in the source. That way,
simple use cases would still compile without complaint.
(As long as only a single, precisely define
Steven Schveighoffer wrote:
On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
wrote:
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring
You guys are way on the wrong track here.
I'm very much a fan of simple and orthogonal languages. But this
statement has a big problem: it's not clear what one actually considers
to be "simple" and "orthogonal". What people consider to be orthogonal
can vary not only a little, but actually a l
On 31/01/2011 17:01, Ulrik Mikaelsson wrote:
Now, what we need is the audio-equivalent of this:
http://www.youtube.com/watch?v=6NcIJXTlugc
Damn, pretty damn impressive!
--
Bruno Medeiros - Software Engineer
You guys are way on the wrong track here.
I'm very much a fan of simple and orthogonal languages. But this
statement has a big problem: it's not clear what one actually considers
to be "simple" and "orthogonal". What people consider to be orthogonal
can vary not only a little, but actually a l
On 2011-02-10 20:15, Walter Bright wrote:
Nick Sabalausky wrote:
"bearophile" wrote in message
news:iivb5n$na3$1...@digitalmars.com...
auto x;
if (localtime().hours >= 8) {
x = "awake!"
} else {
x = "asleep, go away."
}
log "I'm " + x;
That would be really nice to have in D.
auto x = (lo
On 2/10/11, Walter Bright wrote:
> auto x = (localtime().hours >= 8) ? "awake!" : "asleep, go away.";
Aye, a one liner!
I hate seeing things like this:
if (funcall())
{
var = "foo";
}
else
{
var = "bar";
}
So much clutter instead of using the simple:
var = funcall() ? "foo" : "bar";
I
Nick Sabalausky wrote:
"bearophile" wrote in message
news:iivb5n$na3$1...@digitalmars.com...
auto x;
if (localtime().hours >= 8) {
x = "awake!"
} else {
x = "asleep, go away."
}
log "I'm " + x;
That would be really nice to have in D.
auto x = (localtime().hours >= 8) ? "awake!" : "a
On Thu, 10 Feb 2011 13:59:24 -0500, Steven Schveighoffer
wrote:
No but you can make things easier to avoid writing incorrect code. This
kind of change invites mistakes, because it looks like you have to
completely duplicate your logic, and forgetting to modify one and not
the other happ
On 09/02/2011 12:14, spir wrote:
Hello,
Walter states that inline annotations are useless, since programmers cannot
generally know
which function /should/ be inlined --depending on a variety of factors,
inlining may in
fact be counter-productive.
I hate not being able to force functions to
On Thu, 10 Feb 2011 12:24:02 -0500, Jason House
wrote:
Steven Schveighoffer Wrote:
On Thu, 10 Feb 2011 09:15:36 -0500, Jason House
wrote:
> Don Wrote:
>
>> Andrei once stated a worthy goal: as far as possible, const should be
>> opt-in: it should be possible to code without requiring cons
spir wrote:
> Even then, noone forces D2 to blindly reproduce stupid naming from
> APL/C++, I guess. Or what?
>
Actually, I thought that D had set out to *fix* the stupid mistakes
from C++...
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabbe
On Thursday, February 10, 2011 09:25:25 %u wrote:
> What Phobos modules are currently depreciated or undergoing mayor
> changes right now? And what are their replacements if any?
>
> I suppose std.xml is one. What about std.regex/std.regexp,
> std.stream/std.stdio/std.cstream/std.socketstream, std
On 02/10/2011 05:22 PM, Steven Schveighoffer wrote:
I know this is an old issue, and I found this old bug to describe it (helping
someone in a D.learn thread): http://d.puremagic.com/issues/show_bug.cgi?id=3464
But my question is, what is the value of T in *expected* usage. The bug gives
the exa
What Phobos modules are currently depreciated or undergoing mayor
changes right now? And what are their replacements if any?
I suppose std.xml is one. What about std.regex/std.regexp,
std.stream/std.stdio/std.cstream/std.socketstream, std.bind,
std.boxer/std.variant?
BTW: http://digitalmars.com/d
Steven Schveighoffer Wrote:
> On Thu, 10 Feb 2011 09:15:36 -0500, Jason House
> wrote:
>
> > Don Wrote:
> >
> >> Andrei once stated a worthy goal: as far as possible, const should be
> >> opt-in: it should be possible to code without requiring const on
> >> everything.
> >>
> >> opEquals() i
On 08/02/2011 22:31, Matthias Pleh wrote:
VisualD has some code for automated winapi-conversion:
to build the necessary D translations from the Windows and Visual Studio
SDK
Firstly, can this be used to build D translations from headers other than M$'s own? The
win32 translations in the b
On 30/01/2011 18:55, Tomek Sowiński wrote:
Andrej Mitrovic napisał:
If you really want to set up a column limit that *everyone* has to abide to,
then make a poll to see what everyone can agree on.
Actually that's a splendid idea. Let's take it easy. Regardless of that silly
beef I'm really
On 27/01/2011 18:56, Eric Poggel wrote:
On 1/27/2011 1:32 AM, dwilson wrote:
Beside praying and pestering, what can we D non-experts do to help get
a stable 64-bit dmd available?
Killer D features are strings, slick built in dynamics arrays, no
headers files to keep in sync, and the
other nice
Jean Crystof Wrote:
> How about this?
> spir Wrote:
>
> auto x =
> if (localtime().hours>= 8) {
> "awake!"
> } else {
> "asleep, go away."
> };
>
> log "I'm " + x;
>
> I think it solves the problem of unkown type for x nicely. And it's very
> close to what we already have. someth
On 2/10/11, spir wrote:
> I'm not a great fan of auto, neither, use it would happily live w/o it,
> except
> for functions operating on ranges, that return types coming from who-knows
> where (certainly another planet).
auto is great for rapid prototyping. And so are templated functions.
After I'
spir Wrote:
> On 02/10/2011 06:43 AM, Nick Sabalausky wrote:
> > "bearophile" wrote in message
> > news:iivb5n$na3$1...@digitalmars.com...
> >>
> >> auto x;
> >> if (localtime().hours>= 8) {
> >> x = "awake!"
> >> } else {
> >> x = "asleep, go away."
> >> }
> >> log "I'm " + x;
> >>
> >
>
I know this is an old issue, and I found this old bug to describe it
(helping someone in a D.learn thread):
http://d.puremagic.com/issues/show_bug.cgi?id=3464
But my question is, what is the value of T in *expected* usage. The bug
gives the example:
is(typeof(*T.init) == function)
to te
On 2011-02-09 21:09, Daniel Gibson wrote:
Am 09.02.2011 21:08, schrieb Ary Manzana:
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax like iota,
coming from APL. This makes Phobos and learning D a bit simpler.
I would recommend stop using "
On 2/10/11 12:34 PM, Max Samukha wrote:
On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
On 2/10/11 12:30 AM, Olivier Pisano wrote:
Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax like
iota, co
On 02/10/2011 04:34 PM, Max Samukha wrote:
On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
On 2/10/11 12:30 AM, Olivier Pisano wrote:
Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax like
iota,
On 02/10/2011 06:43 AM, Nick Sabalausky wrote:
"bearophile" wrote in message
news:iivb5n$na3$1...@digitalmars.com...
auto x;
if (localtime().hours>= 8) {
x = "awake!"
} else {
x = "asleep, go away."
}
log "I'm " + x;
That would be really nice to have in D. There's been many times I'
On 02/10/2011 05:18 PM, Andrei Alexandrescu wrote:
On 2/10/11 12:30 AM, Olivier Pisano wrote:
Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax like
iota, coming from APL. This makes Phobos and lear
On Thu, 10 Feb 2011 10:19:50 -0500, Andrei Alexandrescu
wrote:
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEqu
On 2/10/11 2:58 AM, Peter Alexander wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a member function of
Obj
On 2/10/11 12:30 AM, Olivier Pisano wrote:
Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax like
iota, coming from APL. This makes Phobos and learning D a bit simpler.
I would recommend stop using
On Thu, 10 Feb 2011 09:15:36 -0500, Jason House
wrote:
Don Wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a member function of
Obje
On 02/10/2011 10:26 AM, so wrote:
Saying that no one should have to worry about const if they don't want to is a
noble though, I suppose, but I don't think that it's entirely realistic. const
is part of the language, and some things just plain have to be const to work.
And given the prevalence of
On 02/10/2011 10:09 AM, so wrote:
(1) If it is a const member function, then it will have a viral effect on all
objects -- any function called by opEquals will have to be marked const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
Is this point very
Don Wrote:
> Andrei once stated a worthy goal: as far as possible, const should be
> opt-in: it should be possible to code without requiring const on everything.
>
> opEquals() is in conflict with this, since it is a member function of
> Object.
>
> (1) If it is a const member function, then i
On 02/09/2011 11:43 PM, Nick Sabalausky wrote:
Although I do like the inverse approach that D ended up taking: Don't bother
with simplicity/orthogonality at first, just get important features in.
*Then* refactor the internals to shuffle the complexity into the std lib and
simplify the core langu
On 02/09/2011 08:47 PM, Walter Bright wrote:
Nick Sabalausky wrote:
"Walter Bright" wrote in message
news:iicfaa$23j7$1...@digitalmars.com...
http://www.reddit.com/r/programming/comments/fdqdn/google_go_just_got_major_win32_treats_now/c1f62a0
You'd think that things like JS, Haskell, LISP a
On Thu, 10 Feb 2011 03:37:58 -0500, Jonathan M Davis
wrote:
On Thursday 10 February 2011 00:19:38 Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this
Hello all,
"Michel Fortin" wrote in message
news:iiu8dm$10te$1...@digitalmars.com...
> On 2011-02-09 07:49:31 -0500, Bruno Medeiros
> said:
>> On 04/02/2011 20:11, Michel Fortin wrote:
>>> On 2011-02-04 11:12:12 -0500, Bruno Medeiros
>>> said:
>>>
Can Git really have an usable but incomp
On Wed, 09 Feb 2011 22:30:23 +, dsimcha wrote:
> Has anyone been able to get BLAS/LAPACK/SciD working on Windows? If so,
> how?
> The furthest I've gotten is building SciD, downloading BLAS and LAPACK
> prebuilt binaries from http://icl.cs.utk.edu/lapack-for-windows/, and
> using Agner Fog's
On 02/09/2011 08:20 PM, Jesse Phillips wrote:
%u Wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
D is currently very not-orthogonal.
I think you might the person to ask this:
I've seen the concept of orthogonality pop up more and more and it was
especially
prominent in
On 02/10/2011 07:30 AM, Olivier Pisano wrote:
Le 09/02/2011 21:08, Ary Manzana a écrit :
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax like
iota, coming from APL. This makes Phobos and learning D a bit simpler.
I would recommend stop us
On 2011-02-10 04:36:56 -0500, Don said:
so wrote:
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be
marked const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
On 02/09/2011 09:09 PM, Daniel Gibson wrote:
Am 09.02.2011 21:08, schrieb Ary Manzana:
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax like iota,
coming from APL. This makes Phobos and learning D a bit simpler.
I would recommend stop usin
On 02/09/2011 09:08 PM, Ary Manzana wrote:
On 2/9/11 3:54 PM, bearophile wrote:
- There is no need to learn to use a function with a weird syntax like iota,
coming from APL. This makes Phobos and learning D a bit simpler.
I would recommend stop using "weird" names for functions. Sorry if this
On 02/09/2011 08:06 PM, Daniel Gibson wrote:
Also using X in 1..4 is in D is pretty bad if you just want to check if 1
I don't understand your point, here. opIn (or rather opIn_r) ids just 2
comparisons as well for whatever represents an interval i..j. Simulation below.
Denis
struct Interval
On Thu, 10 Feb 2011 10:58:25 +0200, Peter Alexander
wrote:
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a me
Can you think of a use case where the calling function should know that
opEquals() isn't truly const?
I can't think of any.
If we are going to this way, we need all four of them to be const i think.
On Thursday 10 February 2011 01:36:56 Don wrote:
> so wrote:
> >> (1) If it is a const member function, then it will have a viral effect
> >> on all objects -- any function called by opEquals will have to be
> >> marked const.
> >
> > It doesn't look like we can solve this by switching the constne
so wrote:
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be
marked const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
unless we also state that every function in
On Thursday 10 February 2011 01:26:14 so wrote:
> > Saying that no one should have to worry about const if they don't want
> > to is a
> > noble though, I suppose, but I don't think that it's entirely realistic.
> > const
> > is part of the language, and some things just plain have to be const to
>
Saying that no one should have to worry about const if they don't want
to is a
noble though, I suppose, but I don't think that it's entirely realistic.
const
is part of the language, and some things just plain have to be const to
work.
And given the prevalence of immutable with regards to thr
(1) If it is a const member function, then it will have a viral effect
on all objects -- any function called by opEquals will have to be marked
const.
It doesn't look like we can solve this by switching the constness of an
Object.function,
unless we also state that every function in Object
On 10/02/11 8:19 AM, Don wrote:
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on
everything.
opEquals() is in conflict with this, since it is a member function of
Object.
(1) If it is a const member function,
On Thursday 10 February 2011 00:19:38 Don wrote:
> Andrei once stated a worthy goal: as far as possible, const should be
> opt-in: it should be possible to code without requiring const on
> everything.
>
> opEquals() is in conflict with this, since it is a member function of
> Object.
>
> (1) If
Andrei once stated a worthy goal: as far as possible, const should be
opt-in: it should be possible to code without requiring const on everything.
opEquals() is in conflict with this, since it is a member function of
Object.
(1) If it is a const member function, then it will have a viral effe
98 matches
Mail list logo
