Lionello Lunesu wrote:
On 8-12-2009 1:43, Andrei Alexandrescu wrote:
Nice analysis. IMHO this should lead us to reconsider the necessity of
"^^" in the first place. It seems to be adding too little real value
compared to the complexity of defining it.
No, Don's just being awefully thorough. If
Michel Fortin wrote:
On 2009-12-07 01:29:14 -0500, Andrei Alexandrescu
said:
Using double negation !!x throughout, there are only advantages and no
disadvantage. I hit that design with Pacquiao punches over the past
week or so, and couldn't find any shortcoming. It's consistent across
posit
On 2009-12-07 01:29:14 -0500, Andrei Alexandrescu
said:
Using double negation !!x throughout, there are only advantages and no
disadvantage. I hit that design with Pacquiao punches over the past
week or so, and couldn't find any shortcoming. It's consistent across
positive and negated uses,
Walter Bright wrote:
> Simen kjaeraas wrote:
>> Leave it in. WIth unary -, we should also have its archnemesis, the
>> unary +.
>
> Can't have Superman without Lex Luthor!
Well, you can, but the stories would be a good bit less interesting.
So, after months of avoiding shared, I decided to see if I could remove all
my casting away of shared. It looks like things are still pretty buggy (or
at least not particularly easy to use).
"is(T : shared)" gives a parse error
"alias shared T U" silently does the wrong thing.
(Use "alias
Stewart Gordon:
>Which doesn't accommodate anything equivalent to a[$-4 .. $-2].<
In Python:
>>> a = "abcdefgh"
>>> a[-4 : -2]
'ef'
> Or you can also use None, this can useful because you can put None
> inside a variable, etc (while in D you can't put $ inside a variable
> to represent "the en
retard wrote:
Mon, 07 Dec 2009 04:06:14 -0500, Michiel Helvensteijn wrote:
Andrei Alexandrescu Wrote:
What will removing it gain you?
Sancta simplicitas.
Hm.. I don't really buy that argument.
I see you and Walter removing/witholding things (incomparability
operators, logical operator over
On 12/07/2009 08:33 PM, Stewart Gordon wrote:
bearophile wrote:
In Python you usually just omit the value:
a[:5] === a[0 .. 5]
a[5:] === a[5 .. $]
Which doesn't accommodate anything equivalent to a[$-4 .. $-2].
you mean this?
a[-4:-2]
Or you can also use None, this can useful because y
Simen kjaeraas wrote:
Leave it in. WIth unary -, we should also have its archnemesis, the
unary +.
Can't have Superman without Lex Luthor!
bearophile wrote:
In Python you usually just omit the value:
a[:5] === a[0 .. 5]
a[5:] === a[5 .. $]
Which doesn't accommodate anything equivalent to a[$-4 .. $-2].
Or you can also use None, this can useful because you can put None
inside a variable, etc (while in D you can't put $ inside a
On 8-12-2009 1:43, Andrei Alexandrescu wrote:
> Nice analysis. IMHO this should lead us to reconsider the necessity of
> "^^" in the first place. It seems to be adding too little real value
> compared to the complexity of defining it.
No, Don's just being awefully thorough. If you'd revisit all ex
Fri, 27 Nov 2009 06:31:23 -0500, #ponce wrote:
> I think that in the current design of safety, @trusted function and
> normal functions are quite similar. An @unsafe proposal has been
> rejected because of complexity.
>
> But here is a case that is left.
> Sometimes in D1, I found that a functio
Tue, 08 Dec 2009 01:02:04 +0100, Lutger wrote:
> retard wrote:
> ...
>> You surely understand that Walter doesn't have enough time to change
>> this before the Andrei's book is out. So D2 won't be getting this.
>> Besides, he hasn't even said that he likes the syntax. And D can't
>> infer the type
On Mon, Dec 7, 2009 at 4:41 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> Negative exponent values are the only ones with an issue. You can't
>> even write square-root etc with pow using only integers. The argument
>> would have to be a float to even express that, so there is no issu
Bill Baxter wrote:
Negative exponent values are the only ones with an issue. You can't
even write square-root etc with pow using only integers. The argument
would have to be a float to even express that, so there is no issue.
int^^float should be a float just like int/float is a float.
But -1
On Mon, Dec 7, 2009 at 4:04 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Mon, Dec 7, 2009 at 2:56 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> Bill Baxter wrote:
On Mon, Dec 7, 2009 at 2:30 PM, Andrei Alexandrescu
wrote:
>
> Lars T. Kyllingstad wrote:
>>
>
Bill Baxter wrote:
On Mon, Dec 7, 2009 at 2:56 PM, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Mon, Dec 7, 2009 at 2:30 PM, Andrei Alexandrescu
wrote:
Lars T. Kyllingstad wrote:
The fundamental reason why I want opPow so badly is in fact not even how
often I use it. If that was the cas
retard wrote:
...
> You surely understand that Walter doesn't have enough time to change this
> before the Andrei's book is out. So D2 won't be getting this. Besides, he
> hasn't even said that he likes the syntax. And D can't infer the types
> that way, you would need
>
>> Foo ( (auto a, auto b)
Just few comments.
Don:
> Operations involving integers are far less obvious (and are actually
> where a major benefit of an operator can come in).
The pow operator in Python seems to give good results (this also shows why
dynamic typing can be useful, because the return type of a function lik
On Mon, Dec 7, 2009 at 2:52 PM, bearophile wrote:
> Bill Baxter:
>
>> Holy smokes! You actually file bugs in the LLVM database?!
>
> Don't ask me why. Eleven so far, you can't find five of them because in the
> beginning another person has filed them for me in a strange way. LLVM devs
> have as
On Mon, Dec 7, 2009 at 2:56 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Mon, Dec 7, 2009 at 2:30 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> Lars T. Kyllingstad wrote:
The fundamental reason why I want opPow so badly is in fact not even how
often I use it. If that wa
Bill Baxter wrote:
On Mon, Dec 7, 2009 at 2:30 PM, Andrei Alexandrescu
wrote:
Lars T. Kyllingstad wrote:
The fundamental reason why I want opPow so badly is in fact not even how
often I use it. If that was the case, I'd want a special "writefln" operator
as well. The main reason is that expone
Bill Baxter:
> Holy smokes! You actually file bugs in the LLVM database?!
Don't ask me why. Eleven so far, you can't find five of them because in the
beginning another person has filed them for me in a strange way. LLVM devs have
asked me so many times, on IRC.
One of those performance bugs ha
retard wrote:
Mon, 07 Dec 2009 13:17:10 +, Michal Minich wrote:
Hello bearophile,
Michal Minich:
But introduction "{ epx }" as delegate/function literal for functions
with no arguments, which implicitly returns result of the expression,
seems to me as a good idea.
It's a special case,
On Mon, Dec 7, 2009 at 2:30 PM, Andrei Alexandrescu
wrote:
> Lars T. Kyllingstad wrote:
>>
>> The fundamental reason why I want opPow so badly is in fact not even how
>> often I use it. If that was the case, I'd want a special "writefln" operator
>> as well. The main reason is that exponentiation
Lars T. Kyllingstad:
> I searched for FORTRAN code because that's more or less equivalent to
> searching for numerical code. And I think D's "target audience" is
> anyone who needs a fast, close-to-the-metal programming language. This
> definitely includes the scientific community. (There are s
Lars T. Kyllingstad wrote:
The fundamental reason why I want opPow so badly is in fact not even how
often I use it. If that was the case, I'd want a special "writefln"
operator as well. The main reason is that exponentiation is such a basic
mathematical operation, right up there with addition a
On Mon, Dec 7, 2009 at 2:29 PM, bearophile wrote:
> Lars T. Kyllingstad:
>> I also seem to remember someone (was it Don or bearophile, perhaps?)
>> listing various optimisation possibilities that are more readily
>> available if ^^ is a built-in operator.
>
> It was Don, I think.
> Those optimizat
Lars T. Kyllingstad:
> I also seem to remember someone (was it Don or bearophile, perhaps?)
> listing various optimisation possibilities that are more readily
> available if ^^ is a built-in operator.
It was Don, I think.
Those optimizations can be done with the pow, ipow and cpow (real, integer
Andrei Alexandrescu wrote:
Lars T. Kyllingstad wrote:
Andrei Alexandrescu wrote:
Nice analysis. IMHO this should lead us to reconsider the necessity
of "^^" in the first place. It seems to be adding too little real
value compared to the complexity of defining it.
Andrei
It adds a lot of v
KennyTM~ wrote:
On Dec 8, 09 03:03, Lars T. Kyllingstad wrote:
Andrei Alexandrescu wrote:
Don wrote:
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers
"retard" wrote in message
news:hfjnfv$1gv...@digitalmars.com...
> Mon, 07 Dec 2009 04:06:14 -0500, Michiel Helvensteijn wrote:
>
>> Andrei Alexandrescu Wrote:
>>
>>> > What will removing it gain you?
>>>
>>> Sancta simplicitas.
>>
>> Hm.. I don't really buy that argument.
>>
>> I see you and Walt
"downs" wrote in message
news:hfj8qb$ps...@digitalmars.com...
> Nick Sabalausky wrote:
>> I just noticed in D1 that the values for the cases in a switch must be
>> known
>> at compile-time (btw, the docs don't seem somewhat vague on that). Is
>> this
>> also true in D2? If so, I don't suppose w
Sun, 06 Dec 2009 12:24:33 -0500, bearophile wrote:
> Andrei Alexandrescu:
>> Should we yank operator>>>?
>
> We can change it purpose and add the other one: <<< rotate left
rotate right
Or some other user cases
a >>> 1 // count the number of leading 1s
a <<< 0 // count the number of traili
Leandro Lucarella wrote:
Michal Minich, el 7 de diciembre a las 13:51 me escribiste:
Hello Denis,
1. auto t = new Thread ( { a=42 } );
or auto t = new Thread ( () { a=42 } );
It already works, just try it (but don't forget to put a semicolon at
the end).
2. array.findAll (arr, (item) { it
On Dec 8, 09 03:03, Lars T. Kyllingstad wrote:
Andrei Alexandrescu wrote:
Don wrote:
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers are far less obv
On Mon, Dec 7, 2009 at 11:59 AM, Andrei Alexandrescu
wrote:
> Lars T. Kyllingstad wrote:
>>
>> Andrei Alexandrescu wrote:
>>>
>>> Nice analysis. IMHO this should lead us to reconsider the necessity of
>>> "^^" in the first place. It seems to be adding too little real value
>>> compared to the comp
Mon, 07 Dec 2009 04:06:14 -0500, Michiel Helvensteijn wrote:
> Andrei Alexandrescu Wrote:
>
>> > What will removing it gain you?
>>
>> Sancta simplicitas.
>
> Hm.. I don't really buy that argument.
>
> I see you and Walter removing/witholding things (incomparability
> operators, logical operat
Mon, 07 Dec 2009 16:19:37 +0100, klickverbot wrote:
> Denis Koroskin wrote:
>> Although I believe it is implementable and worth the trouble, there is
>> a little gain in this feature and that's probably why it is low in the
>> list. I think that Walter will give a green light if someone implements
Michal Minich, el 7 de diciembre a las 13:51 me escribiste:
> Hello Denis,
>
> >>1. auto t = new Thread ( { a=42 } );
> >>or auto t = new Thread ( () { a=42 } );
> >It already works, just try it (but don't forget to put a semicolon at
> >the end).
> >
> >>2. array.findAll (arr, (item) { item.con
Lars T. Kyllingstad wrote:
Andrei Alexandrescu wrote:
Nice analysis. IMHO this should lead us to reconsider the necessity of
"^^" in the first place. It seems to be adding too little real value
compared to the complexity of defining it.
Andrei
It adds a lot of value to the ones that actual
Michal Minich, el 7 de diciembre a las 13:17 me escribiste:
> Hello bearophile,
>
> >Michal Minich:
> >
> >>But introduction "{ epx }" as delegate/function literal for functions
> >>with no arguments, which implicitly returns result of the expression,
> >>seems to me as a good idea.
> >>
> >It's
Mon, 07 Dec 2009 13:17:10 +, Michal Minich wrote:
> Hello bearophile,
>
>> Michal Minich:
>>
>>> But introduction "{ epx }" as delegate/function literal for functions
>>> with no arguments, which implicitly returns result of the expression,
>>> seems to me as a good idea.
>>>
>> It's a spec
Mon, 07 Dec 2009 16:55:43 +0100, downs wrote:
> Nick Sabalausky wrote:
>> I just noticed in D1 that the values for the cases in a switch must be
>> known at compile-time (btw, the docs don't seem somewhat vague on
>> that). Is this also true in D2? If so, I don't suppose we could get
>> that chang
Lars T. Kyllingstad:
> I'll even go as far as saying that I think 1/2 should either be an error
> or a floating-point value -- or perhaps even a special rational type.
> Integer division is not the same as "ordinary" division, and I think it
> shouldn't use the same symbol. (A backslash would be
Lars T. Kyllingstad wrote:
The decision to dump the built-in complex and imaginary types in favour
of std.complex.Complex was made a long time ago, but nothing has
happened yet. So I have a few questions:
1. Is this still planned for D2?
Far as I know, yes.
2. In that case, when will it ha
Lars T. Kyllingstad wrote:
Andrei Alexandrescu wrote:
Don wrote:
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers are far less obvious (and are actu
Andrei Alexandrescu wrote:
Don wrote:
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers are far less obvious (and are actually
where a major benefit
Lars T. Kyllingstad Wrote:
> The decision to dump the built-in complex and imaginary types in favour
> of std.complex.Complex was made a long time ago, but nothing has
> happened yet. So I have a few questions:
>
> 1. Is this still planned for D2?
>
> 2. In that case, when will it happen?
>
>
Don wrote:
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers are far less obvious (and are actually
where a major benefit of an operator can come in).
Michal Minich wrote:
Hello Andrei,
Should we sack lazy? I'd like it to have a reasonable replacement.
Ideas are welcome!
Andrei
there are 3 sides from which to look at lazy function parameter.
1. Usage - being able to send expressions to function is very important
for writing clear and ni
"klickverbot" wrote in message
news:hfj6eb$ks...@digitalmars.com...
> Denis Koroskin wrote:
>> Although I believe it is implementable and worth the trouble, there is a
>> little gain in this feature and that's probably why it is low in the
>> list.
>> I think that Walter will give a green light
Don wrote:
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers are far less obvious (and are actually
where a major benefit of an operator can come in).
Michiel Helvensteijn wrote:
Andrei Alexandrescu Wrote:
What will removing it gain you?
Sancta simplicitas.
Hm.. I don't really buy that argument.
I see you and Walter removing/witholding things (incomparability
operators, logical operator overloading) from the language, because:
"I can't im
Simen kjaeraas Wrote:
> On Mon, 07 Dec 2009 02:11:16 +0100, Jerry Quinn
> wrote:
> > Well, I could see the value of poviding a rotate operator.
> >
> > Since >>> is tainted, what about >>@ and <<@ for integral rotation?
>
> I was thinking <<> and <>>. They represent the fact that some bits end
Walter Bright wrote:
1. symmetry
2. compatibility with C and many other languages that use it
3. used with operator overloading to convert a user defined type to its
preferred arithmetic representation (a cast can't know what the
'preferred' type is)
4. to create DSL languages, like Spirit, as
FWIW, this guy, David Given,
http://www.cowlark.com/about/, has written an essay about Go
http://www.cowlark.com/2009-11-15-go/
He compares Go against another real but less familiar PL which he refers
to as "Brand X" in his article. As you read the article you wonder just
what language is "Br
On Mon, Dec 7, 2009 at 4:00 AM, Don wrote:
> Michiel Helvensteijn wrote:
>>
>> Andrei Alexandrescu Wrote:
>>
What will removing it gain you?
>>>
>>> Sancta simplicitas.
>>
>> Hm.. I don't really buy that argument.
>>
>> I see you and Walter removing/witholding things (incomparability
>> opera
Nick Sabalausky wrote:
> I just noticed in D1 that the values for the cases in a switch must be known
> at compile-time (btw, the docs don't seem somewhat vague on that). Is this
> also true in D2? If so, I don't suppose we could get that changed before the
> book? It's a real PITA for dynamic c
Denis Koroskin wrote:
> Although I believe it is implementable and worth the trouble, there is a
> little gain in this feature and that's probably why it is low in the list.
> I think that Walter will give a green light if someone implements the
> feature and provides a complete patch.
>
> Any vol
On Dec 7, 09 22:40, Lars T. Kyllingstad wrote:
The decision to dump the built-in complex and imaginary types in favour
of std.complex.Complex was made a long time ago, but nothing has
happened yet. So I have a few questions:
1. Is this still planned for D2?
2. In that case, when will it happen?
The decision to dump the built-in complex and imaginary types in favour
of std.complex.Complex was made a long time ago, but nothing has
happened yet. So I have a few questions:
1. Is this still planned for D2?
2. In that case, when will it happen?
3. Are there any reasons why I shouldn't rep
On Mon, 07 Dec 2009 16:51:29 +0300, Michal Minich
wrote:
Hello Denis,
1. auto t = new Thread ( { a=42 } );
or auto t = new Thread ( () { a=42 } );
It already works, just try it (but don't forget to put a semicolon at
the end).
2. array.findAll (arr, (item) { item.contains ("abc") } ); 3
Hello Denis,
1. auto t = new Thread ( { a=42 } );
or auto t = new Thread ( () { a=42 } );
It already works, just try it (but don't forget to put a semicolon at
the end).
2. array.findAll (arr, (item) { item.contains ("abc") } ); 3. foo (
(a, b) { a + b } );
4. array.findAll (arr, (item) { r
On Mon, 07 Dec 2009 16:17:10 +0300, Michal Minich
wrote:
Hello bearophile,
Michal Minich:
But introduction "{ epx }" as delegate/function literal for functions
with no arguments, which implicitly returns result of the expression,
seems to me as a good idea.
It's a special case, and spec
Hello bearophile,
Michal Minich:
But introduction "{ epx }" as delegate/function literal for functions
with no arguments, which implicitly returns result of the expression,
seems to me as a good idea.
It's a special case, and special cases help to kill languages. It's
not important enough.
B
On Mon, 07 Dec 2009 02:11:16 +0100, Jerry Quinn
wrote:
Walter Bright Wrote:
dsimcha wrote:
> == Quote from KennyTM~ (kenn...@gmail.com)'s article
>> No, it will _silently_ break code that uses >>> as unsigned right
shift.
>
> Well, we could get around this by making >>> an error for a fe
Andrei Alexandrescu wrote:
Is there any good use of unary +? As an aside, Perl programs do use it
occasionally for syntactic disambiguation :o).
Andrei
Leave it in. WIth unary -, we should also have its archnemesis, the unary
+.
--
Simen
On Mon, 07 Dec 2009 13:13:34 +0100, Don wrote:
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers are far less obvious (and are actually
where a m
Michal Minich:
> But introduction
> "{ epx }" as delegate/function literal for functions with no arguments, which
> implicitly returns result of the expression, seems to me as a good idea.
It's a special case, and special cases help to kill languages. It's not
important enough.
But a general sh
bearophile wrote:
Thanks to Andrei to explain the situation better.
Denis Koroskin:
OpTrue also implies opFalse, which is redundant.
C# allows to define both methods, but I don't like that. The compiler can just
return the negation of opTrue, no need of opFalse. Is this a good enough
soluti
Hello Michel,
void logIfFalse(bool condition, pure lazy string message);
logIfFalse(i == 1, createMessage());
I like the idea that of restricting what is passed into function;
void logIfFalse(bool condition, lazy pure nothrow @safe string message);
In wich case, expression passed needs to
Thanks to Andrei to explain the situation better.
Denis Koroskin:
> OpTrue also implies opFalse, which is redundant.
C# allows to define both methods, but I don't like that. The compiler can just
return the negation of opTrue, no need of opFalse. Is this a good enough
solution? It looks better
As has been mentioned in previous posts, a ^^ b should be right
associative and have a precedence between multiplication and unary
operators. That much is clear.
Operations involving integers are far less obvious (and are actually
where a major benefit of an operator can come in).
Using the
Hello Andrei,
Should we sack lazy? I'd like it to have a reasonable replacement.
Ideas are welcome!
Andrei
there are 3 sides from which to look at lazy function parameter.
1. Usage - being able to send expressions to function is very important for
writing clear and nice looking code. I thi
Michiel Helvensteijn wrote:
Andrei Alexandrescu Wrote:
What will removing it gain you?
Sancta simplicitas.
Hm.. I don't really buy that argument.
I see you and Walter removing/witholding things (incomparability operators, logical
operator overloading) from the language, because: "I can't i
Denis Koroskin wrote:
> On Mon, 07 Dec 2009 10:36:16 +0300, Johan Granberg
> wrote:
>
>> Andrei Alexandrescu wrote:
>>
>>> Brad Roberts wrote:
Andrei Alexandrescu wrote:
> bearophile wrote:
>> Walter Bright:
>>
>>> Think of it like the "bool" operator overload. bool gives a
Andrei Alexandrescu Wrote:
> > What will removing it gain you?
>
> Sancta simplicitas.
Hm.. I don't really buy that argument.
I see you and Walter removing/witholding things (incomparability operators,
logical operator overloading) from the language, because: "I can't imagine a
use for it and
On Dec 7, 09 13:11, Don wrote:
KennyTM~ wrote:
On Dec 7, 09 05:12, Andrei Alexandrescu wrote:
I am completely underwhelmed by 1-6 and have strong arguments against
each, but "frankly, my dear" I have bigger problems than that. I have
exactly zero valid reasons I could mention in TDPL, and that'
On Mon, 07 Dec 2009 10:36:16 +0300, Johan Granberg
wrote:
Andrei Alexandrescu wrote:
Brad Roberts wrote:
Andrei Alexandrescu wrote:
bearophile wrote:
Walter Bright:
Think of it like the "bool" operator overload. bool gives a direct
way for user defined times to be tested for if stateme
80 matches
Mail list logo
