On Thursday, 1 September 2016 at 17:10:00 UTC, Seb wrote:
FYI: There's some discussion about it's benefit in comparison
to functional language D does have loops and it's a lot easier
to write and read them.
Some are of that opinion. However, this is D, not Python or Go,
so claims about the
On Thursday, 1 September 2016 at 12:04:51 UTC, qznc wrote:
On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:
D has a lot to offer with regard to functional programming. It
has pure functions and true immutable classes (true = also sub
objects become immutable), which Scala all
On Thursday, 1 September 2016 at 08:04:00 UTC, Bienlein wrote:
D has a lot to offer with regard to functional programming. It
has pure functions and true immutable classes (true = also sub
objects become immutable), which Scala all doesn't have
(because of restrictions of the JVM). Does D have
On Friday, 19 August 2016 at 15:01:58 UTC, Marco Leise wrote:
Am Fri, 19 Aug 2016 13:36:05 +
schrieb Adam D. Ruppe :
On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:
> If we hypothetically switched to a ubyte+ubyte=ubyte
> semantic, then code like
On Tuesday, 30 August 2016 at 18:36:19 UTC, CRAIG DILLABAUGH
wrote:
I am going to vote with Adam here. If memory serves me
correctly what initially drew me in to the D language was a
statement on the main page that "D is not a religion". I think
at the time I had been doing some work with
On 8/31/2016 2:17 AM, Seb wrote:
Done (FYI the translations aren't officially published yet) ;-)
Danke schoen!
On Tuesday, 30 August 2016 at 18:22:59 UTC, Walter Bright wrote:
On 8/30/2016 3:42 AM, Chris wrote:
[...]
I agree it's time to remove comparisons with C++, although
there is room for a "D for C++ Programmers" section and, of
course, "Interfacing D to C++".
I think this will do D good in
On Wednesday, 31 August 2016 at 04:03:32 UTC, Walter Bright wrote:
On 8/30/2016 6:30 PM, ZombineDev wrote:
Your change just went live
http://tour.dlang.org ;)
Thanks! Note that the other languages need updating, too.
Done (FYI the translations aren't officially published yet) ;-)
On 8/30/2016 6:30 PM, ZombineDev wrote:
Your change just went live
http://tour.dlang.org ;)
Thanks! Note that the other languages need updating, too.
On Wednesday, 31 August 2016 at 01:12:10 UTC, Walter Bright wrote:
On 8/30/2016 2:41 PM, mate wrote:
[...]
Thanks for your help!
https://github.com/dlang-tour/english/pull/91
Your change just went live
http://tour.dlang.org ;)
On 8/30/2016 2:41 PM, mate wrote:
On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:
On 8/30/2016 12:56 AM, Markus wrote:
The tour https://tour.dlang.org/ is nearly empty, but on the first page it
states that D is an "evolution of C++ (without the mistakes)" (the real content
is
On 8/30/2016 2:41 PM, mate wrote:
On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:
On 8/30/2016 12:56 AM, Markus wrote:
The tour https://tour.dlang.org/ is nearly empty, but on the first page it
states that D is an "evolution of C++ (without the mistakes)" (the real content
is
On Tuesday, 30 August 2016 at 20:25:42 UTC, Walter Bright wrote:
On 8/30/2016 12:56 AM, Markus wrote:
The tour https://tour.dlang.org/ is nearly empty, but on the
first page it
states that D is an "evolution of C++ (without the mistakes)"
(the real content
is hidden in the menu-sections).
I
On 8/30/2016 12:56 AM, Markus wrote:
The tour https://tour.dlang.org/ is nearly empty, but on the first page it
states that D is an "evolution of C++ (without the mistakes)" (the real content
is hidden in the menu-sections).
I was going to fix that, but can't find where it is on github. The
On 8/30/2016 11:22 AM, Walter Bright wrote:
On 8/30/2016 3:42 AM, Chris wrote:
[...]
I agree it's time to remove comparisons with C++, although there is room for a
"D for C++ Programmers" section and, of course, "Interfacing D to C++".
https://github.com/dlang/dlang.org/pull/1459
On Tuesday, 30 August 2016 at 14:19:02 UTC, Adam D. Ruppe wrote:
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu
wrote:
Sadly if this doesn't float your boat you're unlikely to enjoy
most of what D has to offer. -- Andrei
This might be the most wrong statement you have ever
On 8/30/2016 3:42 AM, Chris wrote:
[...]
I agree it's time to remove comparisons with C++, although there is room for a
"D for C++ Programmers" section and, of course, "Interfacing D to C++".
On 08/30/2016 10:19 AM, Adam D. Ruppe wrote:
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu wrote:
Sadly if this doesn't float your boat you're unlikely to enjoy most of
what D has to offer. -- Andrei
This might be the most wrong statement you have ever said on this forum.
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu
wrote:
On 08/30/2016 06:50 AM, John Burrton wrote:
This is why the example on the front page put me off for a
long time :-
stdin
.byLineCopy
.array
.sort!((a, b) => a > b) // descending order
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu
wrote:
On 08/30/2016 06:50 AM, John Burrton wrote:
This is why the example on the front page put me off for a
long time :-
stdin
.byLineCopy
.array
.sort!((a, b) => a > b) // descending order
On 08/30/2016 03:56 AM, Markus wrote:
On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:
On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
Take a look on this discussion thread and you know WHY D IS NOT SO
POPULAR.
The community discusses technical details and compares D to C++,
On Tuesday, 30 August 2016 at 14:11:56 UTC, Andrei Alexandrescu
wrote:
Sadly if this doesn't float your boat you're unlikely to enjoy
most of what D has to offer. -- Andrei
This might be the most wrong statement you have ever said on this
forum.
D's biggest appeal to me is that it *doesn't*
On 08/30/2016 10:04 AM, Adam D. Ruppe wrote:
C style example
functional style example
That doesn't sounds like a good idea. -- Andrei
On 08/30/2016 06:50 AM, John Burrton wrote:
This is why the example on the front page put me off for a long time :-
stdin
.byLineCopy
.array
.sort!((a, b) => a > b) // descending order
.each!writeln;
Sadly if this doesn't float your boat you're unlikely to
On 08/30/2016 01:50 PM, John Burrton wrote:
> This is why the example on the front page put me off for a long time :-
>
> stdin
> .byLineCopy
> .array
> .sort!((a, b) => a > b) // descending order
> .each!writeln;
>
> It makes the language look like some weird
On Tuesday, 30 August 2016 at 13:42:21 UTC, eugene wrote:
i think it will lead to something like: "Why do they have
different examples for the same thing?"
D is multi paradigm:
C style example
functional style example
With D, your existing expertise carries over from C while
opening
On Tuesday, 30 August 2016 at 13:34:05 UTC, Adam D. Ruppe wrote:
On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:
As I said not really a complaint ... But it d make me think d
was too high level a language with too much 'magic' . Other
people will have different opinions
On Tuesday, 30 August 2016 at 13:34:05 UTC, Adam D. Ruppe wrote:
On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:
As I said not really a complaint ... But it d make me think d
was too high level a language with too much 'magic' . Other
people will have different opinions
On Tuesday, 30 August 2016 at 11:29:45 UTC, John Burton wrote:
As I said not really a complaint ... But it d make me think d
was too high level a language with too much 'magic' . Other
people will have different opinions
Indeed, I'm not a fan of that example either...
but we could turn this
On Tuesday, 30 August 2016 at 11:17:33 UTC, Chris wrote:
On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burrton wrote:
This is why the example on the front page put me off for a
long time :-
stdin
.byLineCopy
.array
.sort!((a, b) => a > b) // descending order
On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burrton wrote:
This is why the example on the front page put me off for a long
time :-
stdin
.byLineCopy
.array
.sort!((a, b) => a > b) // descending order
.each!writeln;
It makes the language look like
On Tuesday, 30 August 2016 at 10:50:17 UTC, John Burton wrote:
I'm willing to admit I might be the only one :P But I'd much
rather see the "better C" side as my first view of typical D
code than this.
And I want to be clear... None of this is a complaint. I just
wanted to post what
On Tuesday, 30 August 2016 at 08:34:23 UTC, eugene wrote:
On Tuesday, 30 August 2016 at 08:00:35 UTC, Markus wrote:
D has its roots in C++ (and C) but is full fledged now and
should
represent its features and strength WITHOUT continuously
referencing C++ and without this repetitive "without
On Tuesday, 30 August 2016 at 07:56:06 UTC, Markus wrote:
Most of the (very good) articles in
https://dlang.org/articles.html compare D-features with C++. If
I want to learn how D templates work, I do not need to know
what is bad in C++-Templates.
True. Any C++ programmer interested in
On Tuesday, 30 August 2016 at 08:00:35 UTC, Markus wrote:
D has its roots in C++ (and C) but is full fledged now and
should
represent its features and strength WITHOUT continuously
referencing C++ and without this repetitive "without mistakes".
...
From my point of view this is misleading for
On Tuesday, 30 August 2016 at 07:56:06 UTC, Markus wrote:
On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:
On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
[...]
Hello,
the url https://dlang.org/overview.html states that "It's a
practical language for practical
On Monday, 29 August 2016 at 14:31:50 UTC, eugene wrote:
On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
Take a look on this discussion thread and you know WHY D IS
NOT SO POPULAR.
The community discusses technical details and compares D to
C++, but there is no clear mission
On Monday, 29 August 2016 at 12:11:34 UTC, Markus wrote:
Take a look on this discussion thread and you know WHY D IS NOT
SO POPULAR.
The community discusses technical details and compares D to
C++, but there is no clear mission statement, there is no
vision statement...
Hello,
the url
Take a look on this discussion thread and you know WHY D IS NOT
SO POPULAR.
The community discusses technical details and compares D to C++,
but there is no clear mission statement, there is no vision
statement and no marketing.
Often you merchandise D as a "system programming language",
On 21/08/16 19:31, Andrei Alexandrescu wrote:
On 08/20/2016 11:25 AM, Shachar Shemesh wrote:
On 20/08/16 00:51, Walter Bright wrote:
On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
Alas, C insisted on making everything int all the time and D followed
that :(
Actually, Adam's suggestion on how
On Sunday, 21 August 2016 at 16:31:41 UTC, Andrei Alexandrescu
wrote:
Consider:
void fun(byte);
void fun(int);
fun(b + c);
Does anybody actually do that in the real world? Given the int
promotion rule, such an overload is something i'd flag as always
bug prone and confusing anyway.
With
On Monday, 22 August 2016 at 05:54:17 UTC, Shachar Shemesh wrote:
On 21/08/16 12:47, ag0aep6g wrote:
Consider `ubyte(255) * ubyte(2) / ubyte(2)`. If the operands
are
promoted to a larger type, you get 255 as the result. If they
are not,
you have the equivalent of `ubyte x = 255; x *= 2; x /=
On Monday, 22 August 2016 at 07:05:01 UTC, Shachar Shemesh wrote:
On 22/08/16 09:31, Vadim Lopatin wrote:
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh
- No RAII support, despite the fact everybody here seems to
think that
D supports RAII.
Shachar
There IS RAII in D.
I'm using
On Sunday, 21 August 2016 at 23:07:43 UTC, Solomon E wrote:
The D spec is full of errors, literally, or teasers sometimes.
Erroneous code should be omitted from a spec, or at least
clearly marked such as by a red background.
I'd like to respond critically to my own silly comment.
On 22/08/16 09:31, Vadim Lopatin wrote:
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:
I'll give some highlights, but those are, mostly, things that I've
already listed in this forum and in my lightening talk.
- No RAII support, despite the fact everybody here seems to think
On Friday, 12 August 2016 at 19:29:42 UTC, Shachar Shemesh wrote:
I'll give some highlights, but those are, mostly, things that
I've already listed in this forum and in my lightening talk.
- No RAII support, despite the fact everybody here seems to
think that D supports RAII.
Shachar
There
On 21/08/16 12:47, ag0aep6g wrote:
On 08/21/2016 07:12 AM, Shachar Shemesh wrote:
During static analysis, keep both the "most expanded" and the "least
expanded" type of the expression parsed so far. "Least expanded" is the
largest type actually used in the expression.
What's "most expanded"?
On Sunday, 21 August 2016 at 17:26:24 UTC, Walter Bright wrote:
On 8/21/2016 2:47 AM, ag0aep6g wrote:
Upon use of the value, resolve which type to actually use for
it. If the
use type requests a type between least and most, use that
type for
evaluating the entire expression. If the use
On Sunday, 21 August 2016 at 21:31:07 UTC, Bill Hicks wrote:
On Sunday, 21 August 2016 at 12:51:16 UTC, Lodovico Giaretta
wrote:
Your offensive tone, your attitude to pointing at a single
person as the source of the problems,
My friend (or foe), please don't get it twisted. If D had been
On Sunday, 21 August 2016 at 12:51:16 UTC, Lodovico Giaretta
wrote:
Your offensive tone, your attitude to pointing at a single
person as the source of the problems,
My friend (or foe), please don't get it twisted. If D had been a
huge success, it's Andrei and Walter who were going to
On 8/21/2016 2:47 AM, ag0aep6g wrote:
Upon use of the value, resolve which type to actually use for it. If the
use type requests a type between least and most, use that type for
evaluating the entire expression. If the use requests a type outside
that range, use the one closest (and, if the use
On Sunday, 21 August 2016 at 15:05:11 UTC, Mike Parker wrote:
On Sunday, 21 August 2016 at 12:51:16 UTC, Lodovico Giaretta
wrote:
Your offensive tone, your attitude to pointing at a single
person as the source of the problems, your improper use of
low-level stereotypes and non-technical
On 08/21/2016 01:12 AM, Shachar Shemesh wrote:
I'll suggest an algorithmic definition of (my interpretation of) Adam's
proposal:
During static analysis, keep both the "most expanded" and the "least
expanded" type of the expression parsed so far. "Least expanded" is the
largest type actually
On 08/20/2016 11:25 AM, Shachar Shemesh wrote:
On 20/08/16 00:51, Walter Bright wrote:
On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
Alas, C insisted on making everything int all the time and D followed
that :(
Actually, Adam's suggestion on how things should work is precisely how C
works
On Sunday, 21 August 2016 at 12:51:16 UTC, Lodovico Giaretta
wrote:
Your offensive tone, your attitude to pointing at a single
person as the source of the problems, your improper use of
low-level stereotypes and non-technical pointless argumentation
are definitely out of place.
He's a
On Sunday, 21 August 2016 at 12:37:35 UTC, Bill Hicks wrote:
[...]
Your offensive tone, your attitude to pointing at a single person
as the source of the problems, your improper use of low-level
stereotypes and non-technical pointless argumentation are
definitely out of place.
That's a
On Saturday, 20 August 2016 at 09:03:50 UTC, Lodovico Giaretta
wrote:
At this point I'd like to know which non-tumoral language we
should all be using...
(I know I shouldn't feed the trolls, but I'm truly interested
in knowing what's his ideal language).
D++, haha, just kidding.
If you
On 08/21/2016 07:12 AM, Shachar Shemesh wrote:
During static analysis, keep both the "most expanded" and the "least
expanded" type of the expression parsed so far. "Least expanded" is the
largest type actually used in the expression.
What's "most expanded"?
Upon use of the value, resolve
On Friday, 19 August 2016 at 02:59:40 UTC, Adam D. Ruppe wrote:
On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
Garbage collector is in a few libraries as well. I think the
only problem I had with that is that the std.range library has
severely reduced functionality when using
On 20/08/16 21:00, Walter Bright wrote:
On 8/20/2016 8:25 AM, Shachar Shemesh wrote:
Actually, Adam's suggestion on how things should work is precisely how
C works
No, it's subtly different. Which is my point that one must be very, very
careful when proposing different behavior.
Can you
On 8/20/2016 8:25 AM, Shachar Shemesh wrote:
Actually, Adam's suggestion on how things should work is precisely how C works
No, it's subtly different. Which is my point that one must be very, very careful
when proposing different behavior.
On 20/08/16 00:51, Walter Bright wrote:
On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
Alas, C insisted on making everything int all the time and D followed
that :(
Actually, Adam's suggestion on how things should work is precisely how C
works (except it trails off at int).
a = b + c;
if b
On 19 August 2016 at 00:50, John Smith via Digitalmars-d
wrote:
> Well there are some things I feel could be improved, a lot of the things are
> really just minor but what is a deal breaker for me mostly is the compilers.
> The GCC and Clang implementations are really
On Saturday, 20 August 2016 at 08:57:48 UTC, Bill Hicks wrote:
On Saturday, 20 August 2016 at 06:11:54 UTC, rikki cattermole
wrote:
And yet it is steadily growing.
A brain tumor grows too, until it kills. We might have lost
the battles with programming languages such as JavaScript, C++,
On Saturday, 20 August 2016 at 06:11:54 UTC, rikki cattermole
wrote:
And yet it is steadily growing.
A brain tumor grows too, until it kills. We might have lost the
battles with programming languages such as JavaScript, C++, etc,
but we still have a fighting chance against D, and we must
On Saturday, 20 August 2016 at 06:08:21 UTC, Bill Hicks wrote:
F*CK, here we go again.
Why do you spend your precious time posting these messages? Are
you real Batman?
On 20/08/2016 6:08 PM, Bill Hicks wrote:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
For years, i was travelling along Golang, Rust, Perl, Ruby, Python,
PHP, JScript, JVM Languages.
Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many more
that i can't remember.
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
For years, i was travelling along Golang, Rust, Perl, Ruby,
Python, PHP, JScript, JVM Languages.
Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many
more that i can't remember.
I'm 24 years old, my first lang was PHP
On Saturday, 20 August 2016 at 00:19:30 UTC, Daniel wrote:
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
Hope this helps,
Daniel
BTW, I'm not the guy in that Gravatar image... ;-)
Daniel
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
I always ignored D, i prejudiced that D failed, because nobody
were talking about it. I decided to check it yesterday, it has
excellent documentation, i almost covered all aspects. I think
D is much better than the most of the
On 8/19/2016 8:19 AM, Adam D. Ruppe wrote:
You're working with float anyway, so I believe the price is paid even by today's
C rules.
Nope, the operands of integral sub-expressions are not promoted to float.
The intermediates might be different though, I'm not sure.
On 8/18/2016 7:59 PM, Adam D. Ruppe wrote:
Alas, C insisted on making everything int all the time and D followed that :(
One would have to be *really* sure of their ground in coming up with allegedly
better rules.
On Friday, 19 August 2016 at 15:01:58 UTC, Marco Leise wrote:
Float math is slow compared to integer math and precision loss
occurs when this rule is also applied to (u)int and (u)long
with only the deprecated (as per amd64 spec) real type being
large enough for 64-bit integers.
You're working
Am Fri, 19 Aug 2016 13:36:05 +
schrieb Adam D. Ruppe :
> On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:
> > If we hypothetically switched to a ubyte+ubyte=ubyte semantic,
> > then code like this breaks silently:
>
> However, if it took the entire
On Friday, 19 August 2016 at 08:31:39 UTC, Marco Leise wrote:
If we hypothetically switched to a ubyte+ubyte=ubyte semantic,
then code like this breaks silently:
However, if it took the entire statement into account, it could
handle that... by my rule, it would see there's a float in there
Am Mon, 15 Aug 2016 10:54:11 -0700
schrieb Ali Çehreli :
> On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote:
> > On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
>
> >> Also, part of our
> >> problems with this is that introspection also does not see refs, which
> >>
Am Thu, 18 Aug 2016 22:50:27 +
schrieb John Smith :
> Well you could say the same for the same for int. Why isn't "int
> + int = long"? Right now it is following the rule "int + int =
> int".
I believe in C, int reflects the native machine word that the
CPU always uses
On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
Garbage collector is in a few libraries as well. I think the
only problem I had with that is that the std.range library has
severely reduced functionality when using static arrays.
std.range is one of the libraries that has never
On 08/19/2016 12:50 AM, John Smith wrote:
Well there are some things I feel could be improved, a lot of the things
are really just minor but what is a deal breaker for me mostly is the
compilers. The GCC and Clang implementations are really far behind in
terms of the version, so they are missing
Hei John, I read over the first part of your message and it seems
that same information you got is quite outdated:
On Thursday, 18 August 2016 at 22:50:27 UTC, John Smith wrote:
Well there are some things I feel could be improved, a lot of
the things are really just minor but what is a deal
Well there are some things I feel could be improved, a lot of the
things are really just minor but what is a deal breaker for me
mostly is the compilers. The GCC and Clang implementations are
really far behind in terms of the version, so they are missing a
lot of features. A lot of the
On 08/14/2016 07:07 AM, Andrei Alexandrescu wrote:
> On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
>> Also, part of our
>> problems with this is that introspection also does not see refs, which
>> causes the following two functions to report the same signature:
>>
>> void func1(int arg);
>>
On Monday, 15 August 2016 at 13:10:01 UTC, Emre Temelkuran wrote:
It's easy to understand conservative programmers, you can even
use C++ for web programming but it's waste of time and it won't
give you the performance of Dropoid toolkit for Java. Also it's
reliability is depends on your
It's easy to understand conservative programmers, you can even
use C++ for web programming but it's waste of time and it won't
give you the performance of Dropoid toolkit for Java. Also it's
reliability is depends on your skills. Everyone leaving lower
level languages other than the internet
On Sunday, 14 August 2016 at 18:03:24 UTC, Shachar Shemesh wrote:
I must confess that I have never heard of this rule in C
before encountering it in D.
Which rule?
The rule that says "ubyte + ubyte = uint".
On 14/08/16 21:35, Andrei Alexandrescu wrote:
I should add that as long as the .di does not import the .d, the
slowdown due to the computed table will not occur. So the worry is not
warranted.
I'm not sure the above is true in cases of imports that are not circular
for the optimal dis, but
On Friday, 12 August 2016 at 18:04:53 UTC, Andrei Alexandrescu
wrote:
On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:
Honestly, I don't think that shared is broken.
Yes. It is broken.
shared int x;
++x; // error, must use
On 8/14/16 11:40 PM, Jonathan M Davis via Digitalmars-d wrote:
On Sunday, August 14, 2016 14:35:49 Andrei Alexandrescu via Digitalmars-d
wrote:
On 8/14/16 2:03 PM, Shachar Shemesh wrote:
On 14/08/16 17:07, Andrei Alexandrescu wrote:
On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
I must
On Sunday, August 14, 2016 14:35:49 Andrei Alexandrescu via Digitalmars-d
wrote:
> On 8/14/16 2:03 PM, Shachar Shemesh wrote:
> > On 14/08/16 17:07, Andrei Alexandrescu wrote:
> >> On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
> >>> I must confess that I have never heard of this rule in C before
On Monday, 1 August 2016 at 15:31:35 UTC, Emre Temelkuran wrote:
For years, i was travelling along Golang, Rust, Perl, Ruby,
Python, PHP, JScript, JVM Languages.
Lastly Crystal Lang and Nimrod, Julia, Haskell, Swift and many
more that i can't remember.
I'm 24 years old, my first lang was PHP
On 8/14/2016 11:03 AM, Shachar Shemesh wrote:
Which rule?
The rule that says "ubyte + ubyte = uint".
Many people are surprised by this rule, but it is deeply embedded in C and C++.
In C99,
---
6.3.1.8 Usual Arithmetic Conversions
Then the following rules are
On 8/14/16 2:03 PM, Shachar Shemesh wrote:
On 14/08/16 17:07, Andrei Alexandrescu wrote:
On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
So that is slide 4. Could you please give a bit of detail?
http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
OK. One
On 14/08/16 17:07, Andrei Alexandrescu wrote:
> On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
>>> So that is slide 4. Could you please give a bit of detail?
>>
>> http://www.digitalmars.com/d/archives/digitalmars/D/What_is_going_on_here_257862.html
>>
>
> OK. One thing we can't stress enough is
On Sun, 14 Aug 2016 08:18:08 +0300, Shachar Shemesh wrote:
> The first is that you can rarely put "const" on anything, meaning you
> lose the power that C++'s guarantee gave you, and not gain enough in
> return.
I can often put const on things. However, it's an added step, the
compiler doesn't
On 08/14/2016 01:18 AM, Shachar Shemesh wrote:
On 14/08/16 03:26, Andrei Alexandrescu wrote:
On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
I'm also tempted to argue that making shared virtually unusable without
casting it away would be a good idea
It's a bad idea, no two
On 14/08/16 03:26, Andrei Alexandrescu wrote:
On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
I'm also tempted to argue that making shared virtually unusable without
casting it away would be a good idea
It's a bad idea, no two ways about it. The bummer here is that this is
On Sunday, 14 August 2016 at 00:26:31 UTC, Andrei Alexandrescu
wrote:
On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d
wrote:
I'm also tempted to argue that making shared virtually
unusable without
casting it away would be a good idea
It's a bad idea, no two ways about it. The
On 08/13/2016 05:57 PM, Jonathan M Davis via Digitalmars-d wrote:
I'm also tempted to argue that making shared virtually unusable without
casting it away would be a good idea
It's a bad idea, no two ways about it. The bummer here is that this is
the only topic (and one where D gets it right)
On 8/13/2016 2:57 PM, Jonathan M Davis via Digitalmars-d wrote:
I'm also tempted to argue that making shared virtually unusable without
casting it away would be a good idea - particularly when you consider that
most code that uses shared is going to need to cast it away to do anything
with it
On Saturday, August 13, 2016 16:45:16 Steven Schveighoffer via Digitalmars-d
wrote:
> Hey, that's fine. I'd rather work on other things too. Shared just seems
> like an unfulfilled promise, with half-implemented protections.
>
> I'd like to just see shared be unusable, and make people cast away
>
1 - 100 of 168 matches
Mail list logo