On Thursday, 20 July 2017 at 16:15:43 UTC, porter wrote:
On Thursday, 20 July 2017 at 15:40:04 UTC, Wulfklaue wrote:
the problems are greater than thought
http://forum.dlang.org/thread/bqlfknpsdetzoxuxr...@forum.dlang.org
On 7/22/2017 6:03 PM, Ali Çehreli wrote:
Are the following floating operators gone?
!> !< !>= !<= <> !<> <>= !<>=
They still appear at least on the following pages:
http://dlang.org/spec/lex.html#tokens
https://wiki.dlang.org/Operator_precedence
Thanks to Andrew Edwards's warning an
Are the following floating operators gone?
!> !< !>= !<= <> !<> <>= !<>=
They still appear at least on the following pages:
http://dlang.org/spec/lex.html#tokens
https://wiki.dlang.org/Operator_precedence
Thanks to Andrew Edwards's warning and unless someone objects, I'm
removing them
On 7/22/2017 1:07 PM, Vladimir Panteleev wrote:
Git blames you:
https://github.com/dlang/dlang.org/commit/4cd3f38bbabdde30b280738dab4f4184c06f05f9
Ah, thanks for finding this. It was in response to:
https://issues.dlang.org/show_bug.cgi?id=5132
i.e. it was documenting existing behavior.
Jerry wrote:
What code would break? Are there any examples of D code that would break
as a result of the change?
basically, any template that has small integral type T and does unary +/-/~
on it. and there *is* such code in phobos, and it's not explicitly tested
for different integral sizes.
On Saturday, 22 July 2017 at 10:51:05 UTC, ketmar wrote:
Walter Bright wrote:
2. Codify existing practice, since it has been that way
forever. Not matching C has caused problems, see 16997 and
17637. It may cause more serious silent problems for people
converting C code to D code.
i'd say "
On Saturday, 22 July 2017 at 10:44:04 UTC, Walter Bright wrote:
Note that the spec says:
"Note: unlike in C and C++, the usual integral promotions are
not performed prior to the complement operation."
http://dlang.org/spec/expression.html#complement_expressions
Where did that come from?
On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote:
In the forum, I saw a thread about someone working on a new GC.
Just wanted to know if there's any updates on that. And what
issues is it going to fix..
Personally, I would be greatly delighted if it acknowledges the
Stop-The-World proble
On Saturday, 22 July 2017 at 10:51:05 UTC, ketmar wrote:
Walter Bright wrote:
2. Codify existing practice, since it has been that way
forever. Not matching C has caused problems, see 16997 and
17637. It may cause more serious silent problems for people
converting C code to D code.
i'd say "
This affects:
~ubyte: all values
-ubyte: all values
-byte: -128 (0x80)
~ushort: all values
-ushort: all values
-short: -32768 (0x8000)
On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
Due to improved ABI handling a subset of slices of complex
structs work now :)
The following code will correctly compile with newCTFE.
struct NA
{
string name;
uint age;
}
NA[] make5(string name)
{
On Saturday, 22 July 2017 at 14:20:24 UTC, Russel Winder wrote:
On Sat, 2017-07-22 at 13:27 +, aedt via Digitalmars-d wrote:
[…]
D without the GC isn't at all interesting, might as well use Go
in that case. So D only gets traction if it keeps a GC.
Go people are also trying to make thei
On Saturday, 22 July 2017 at 16:35:03 UTC, Igor Shirkalin wrote:
On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote:
On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote:
In the forum, I saw a thread about someone working on a new
GC. Just wanted to know if there's any updates on that.
On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote:
On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote:
In the forum, I saw a thread about someone working on a new
GC. Just wanted to know if there's any updates on that. And
what issues is it going to fix..
Personally, I would be gre
On 22.07.2017 16:20, Russel Winder via Digitalmars-d wrote:
D without the GC isn't at all interesting, might as well use Go in that
case.
Uh, no.
On Saturday, 22 July 2017 at 15:13:12 UTC, Ali wrote:
On Saturday, 22 July 2017 at 14:39:17 UTC, Moritz Maxeiner
wrote:
On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
Unless some miracle happens and makes the GC better by
preventing stop-the-world
I have yet to see a (working, correct
On Saturday, 22 July 2017 at 14:39:17 UTC, Moritz Maxeiner wrote:
On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
Unless some miracle happens and makes the GC better by
preventing stop-the-world
I have yet to see a (working, correct) non-STW GC that doesn't
make other trade offs not ac
On Friday, 21 July 2017 at 19:36:08 UTC, H. S. Teoh wrote:
However, I think the presentation of the DIP needs some work.
For example, the rationales and lines of reasoning that
eventually led to the currently proposed syntax, both from the
original draft of this DIP and from the ensuing discuss
On Saturday, 22 July 2017 at 13:27:03 UTC, aedt wrote:
Unless some miracle happens and makes the GC better by
preventing stop-the-world
I have yet to see a (working, correct) non-STW GC that doesn't
make other trade offs not acceptable for D (extra thread(s),
memory barriers for all writes, e
On Saturday, 22 July 2017 at 11:50:40 UTC, Stefan Koch wrote:
tuple map and array are all pretty expensive.
please profile.
Well a bit more compile time isn't the end of the world, and by
far not the only metric (e.g. readability and maintainability
also rank high). You're slightly obsessed
On Sat, 2017-07-22 at 13:27 +, aedt via Digitalmars-d wrote:
>
[…]
> Unless some miracle happens and makes the GC better by preventing
> stop-the-world, or gets rid of the GC, D will not get any more
> attention.
D without the GC isn't at all interesting, might as well use Go in that
case.
On Friday, 14 July 2017 at 08:57:17 UTC, Wulfklaue wrote:
https://blog.sourced.tech/post/language_migrations/
A recent article where github programming languages popularity
and migration got analysed was very interesting but it showed
one noticeable thing:
[...]
Unless some miracle happens
On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote:
[ ... ]
Hi Guys,
Another work-filled two day went by.
And here is the fruit of the labor:
int[2][3] split(int[6] a)
{
int[2][3] result;
foreach (i; 0 .. typeof(result[0]).length)
{
foreach (j; 0 .. result.length)
{
On Friday, 21 July 2017 at 20:44:13 UTC, Enamex wrote:
On Thursday, 20 July 2017 at 22:02:32 UTC, Walter Bright wrote:
[...]
How about this (if I'm not mistaken, this's only one template
instantiation per tuple-type&extracted-index):
[...]
tuple map and array are all pretty expensive.
pl
Walter Bright wrote:
2. Codify existing practice, since it has been that way forever. Not
matching C has caused problems, see 16997 and 17637. It may cause more
serious silent problems for people converting C code to D code.
i'd say "codify, and add warning". since i patched the warning into
They are supposed to match C. But they don't for unary operators + - ~, and as
far as I can tell never did.
https://issues.dlang.org/show_bug.cgi?id=16997
https://issues.dlang.org/show_bug.cgi?id=17637
Note that the spec says:
"Note: unlike in C and C++, the usual integral promotions are n
On Saturday, 22 July 2017 at 10:17:49 UTC, Temtaime wrote:
The new precise GC will be never added to druntime.
It is dead, man.
Why?
On Saturday, 22 July 2017 at 04:53:17 UTC, aedt wrote:
In the forum, I saw a thread about someone working on a new GC.
Just wanted to know if there's any updates on that. And what
issues is it going to fix..
Personally, I would be greatly delighted if it acknowledges the
Stop-The-World proble
On Saturday, 22 July 2017 at 03:05:55 UTC, aberba wrote:
How about this in current syntax? (that's what I do)
int func(int a)
in
{
assert(a >= 0);
}
out(result)
{
assert(result >= 2);
}
body
{
return 2 * a;
}
I can only restate my opinion against th
29 matches
Mail list logo
