On Saturday, 8 September 2018 at 14:20:10 UTC, Laeeth Isharc
wrote:
Religions have believers but not supporters - in fact saying
you are a supporter says you are not a member of that faith or
community.
If you are a supporter of Jesus Christ's efforts, then you most
certainly are a
On Saturday, September 8, 2018 8:05:04 AM MDT Laeeth Isharc via Digitalmars-
d wrote:
> On Thursday, 6 September 2018 at 20:15:22 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, September 6, 2018 1:04:45 PM MDT aliak via
> >
> > Digitalmars-d wrote:
> >> D makes the code-point case default and
On Thursday, September 6, 2018 3:15:59 PM MDT aliak via Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 20:15:22 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, September 6, 2018 1:04:45 PM MDT aliak via
> >
> > Digitalmars-d wrote:
> >> D makes the code-point case default and hence that
On Thursday, 6 September 2018 at 14:42:14 UTC, Chris wrote:
On Thursday, 6 September 2018 at 14:30:38 UTC, Guillaume Piolat
wrote:
On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote:
And autodecode is a good example of experts getting it wrong,
because, you know, you cannot be an
On Thursday, 6 September 2018 at 20:15:22 UTC, Jonathan M Davis
wrote:
On Thursday, September 6, 2018 1:04:45 PM MDT aliak via
Digitalmars-d wrote:
D makes the code-point case default and hence that becomes the
simplest to use. But unfortunately, the only thing I can think
of
that requires
On Thursday, 6 September 2018 at 17:19:01 UTC, Joakim wrote:
No, Swift counts grapheme clusters by default, so it gives 1. I
suggest you read the linked Swift chapter above. I think it's
the wrong choice for performance, but they chose to emphasize
intuitiveness for the common case.
I like
On Thursday, 6 September 2018 at 20:15:22 UTC, Jonathan M Davis
wrote:
On Thursday, September 6, 2018 1:04:45 PM MDT aliak via
Digitalmars-d wrote:
D makes the code-point case default and hence that becomes the
simplest to use. But unfortunately, the only thing I can think
of
that requires
On Thursday, September 6, 2018 1:04:45 PM MDT aliak via Digitalmars-d wrote:
> D makes the code-point case default and hence that becomes the
> simplest to use. But unfortunately, the only thing I can think of
> that requires code point representations is when dealing
> specifically with unicode
On Thursday, 6 September 2018 at 16:44:11 UTC, H. S. Teoh wrote:
On Thu, Sep 06, 2018 at 02:42:58PM +, Dukc via
Digitalmars-d wrote:
On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
> // D
> auto a = "á";
> auto b = "á";
> auto c = "\u200B";
> auto x = a ~ c ~ a;
> auto y = b ~
On Thursday, September 6, 2018 10:44:11 AM MDT H. S. Teoh via Digitalmars-d
wrote:
> On Thu, Sep 06, 2018 at 02:42:58PM +, Dukc via Digitalmars-d wrote:
> > On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
> > > // D
> > > auto a = "á";
> > > auto b = "á";
> > > auto c = "\u200B";
On Thursday, 6 September 2018 at 16:44:11 UTC, H. S. Teoh wrote:
On Thu, Sep 06, 2018 at 02:42:58PM +, Dukc via
Digitalmars-d wrote:
On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
> // D
> auto a = "á";
> auto b = "á";
> auto c = "\u200B";
> auto x = a ~ c ~ a;
> auto y = b ~
On Thu, Sep 06, 2018 at 02:42:58PM +, Dukc via Digitalmars-d wrote:
> On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
> > // D
> > auto a = "á";
> > auto b = "á";
> > auto c = "\u200B";
> > auto x = a ~ c ~ a;
> > auto y = b ~ c ~ b;
> >
> > writeln(a.length); // 2 wtf
> >
On Thu, Sep 6, 2018 at 4:45 PM Dukc via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
> > // D
> > auto a = "á";
> > auto b = "á";
> > auto c = "\u200B";
> > auto x = a ~ c ~ a;
> > auto y = b ~ c ~ b;
> >
> > writeln(a.length);
On Thursday, 6 September 2018 at 14:42:14 UTC, Chris wrote:
Usually a sign to move on...
You have said that at least 10 times in this very thread.
Doomsayers are as old as D. It will be doing OK.
On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
Hehe, it's already a bit laughable that correctness is not
preferred.
// Swift
let a = "á"
let b = "á"
let c = "\u{200B}" // zero width space
let x = a + c + a
let y = b + c + b
print(a.count) // 1
print(b.count) // 1
print(x.count)
On Thursday, 6 September 2018 at 14:30:38 UTC, Guillaume Piolat
wrote:
On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote:
And autodecode is a good example of experts getting it wrong,
because, you know, you cannot be an expert in all fields. I
think the problem was that it was
On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
// D
auto a = "á";
auto b = "á";
auto c = "\u200B";
auto x = a ~ c ~ a;
auto y = b ~ c ~ b;
writeln(a.length); // 2 wtf
writeln(b.length); // 3 wtf
writeln(x.length); // 7 wtf
writeln(y.length); // 9 wtf
writeln(a == b); // false wtf
On Thursday, 6 September 2018 at 14:33:27 UTC, rikki cattermole
wrote:
Either decide a list of conditions before we can break to
remove it, or yes lets let this idea go. It isn't helping
anyone.
Can't you just let mark it as deprecated and provide a library
compatibility range (100%
On 07/09/2018 2:30 AM, Guillaume Piolat wrote:
On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote:
And autodecode is a good example of experts getting it wrong, because,
you know, you cannot be an expert in all fields. I think the problem
was that it was discovered too late.
There
On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote:
And autodecode is a good example of experts getting it wrong,
because, you know, you cannot be an expert in all fields. I
think the problem was that it was discovered too late.
There are very valid reasons not to talk about
On Wednesday, 5 September 2018 at 22:00:27 UTC, H. S. Teoh wrote:
Because grapheme decoding is SLOW, and most of the time you
don't even need it anyway. SLOW as in, it will easily add a
factor of 3-5 (if not worse!) to your string processing time,
which will make your natively-compiled D code
On Thursday, 6 September 2018 at 11:01:55 UTC, Guillaume Piolat
wrote:
So Unicode in D works EXACTLY as expected, yet people in this
thread act as if the house is on fire.
Expected by who? The Unicode expert or the user?
D dying because of auto-decoding? Who can possibly think that
in
On Thursday, 6 September 2018 at 11:01:55 UTC, Guillaume Piolat
wrote:
Let me break that to you: core developer are language experts.
The rest of us are users, that yes it doesn't make us
necessarily qualified to design a language.
Who?
On Thursday, 6 September 2018 at 11:43:31 UTC, ag0aep6g wrote:
You say that D users shouldn't need a '"Unicode license" before
they do anything with strings'. And you say that Python 3 gets
it right (or maybe less wrong than D).
But here we see that Python requires a similar amount of
On 09/06/2018 12:40 PM, Chris wrote:
To avoid this you have to normalize and recompose any decomposed
characters. I remember that Mac OS X used (and still uses?) decomposed
characters by default, so when you typed 'á' into your cli, it would
automatically decompose it to 'a' + acute. `string`
On Thursday, 6 September 2018 at 11:19:14 UTC, Chris wrote:
One problem imo is that they mixed the terms up: "Grapheme: A
minimally distinctive unit of writing in the context of a
particular writing system." In linguistics a grapheme is not a
single character like "á" or "g". It may also be
On Thursday, 6 September 2018 at 10:44:45 UTC, Joakim wrote:
[snip]
You're not being fair here, Chris. I just saw this SO question
that I think exemplifies how most programmers react to Unicode:
"Trying to understand the subtleties of modern Unicode is
making my head hurt. In particular,
On Wednesday, 5 September 2018 at 07:48:34 UTC, Chris wrote:
import std.array : array;
import std.stdio : writefln;
import std.uni : byCodePoint, byGrapheme;
import std.utf : byCodeUnit;
void main() {
string first = "á";
writefln("%d", first.length); // prints 2
auto firstCU =
On Thursday, 6 September 2018 at 09:35:27 UTC, Chris wrote:
On Thursday, 6 September 2018 at 08:44:15 UTC, nkm1 wrote:
On Wednesday, 5 September 2018 at 07:48:34 UTC, Chris wrote:
On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright
wrote:
Autodecode - I've suffered under that, too.
On Thursday, 6 September 2018 at 10:22:22 UTC, ag0aep6g wrote:
On 09/06/2018 09:23 AM, Chris wrote:
Python 3 gives me this:
print(len("á"))
1
Python 3 also gives you this:
print(len("á"))
2
(The example might not survive transfer from me to you if
Unicode normalization happens along the
On 09/06/2018 09:23 AM, Chris wrote:
Python 3 gives me this:
print(len("á"))
1
Python 3 also gives you this:
print(len("á"))
2
(The example might not survive transfer from me to you if Unicode
normalization happens along the way.)
That's when you enter the 'á' as 'a' followed by U+0301
On Thursday, 6 September 2018 at 08:44:15 UTC, nkm1 wrote:
On Wednesday, 5 September 2018 at 07:48:34 UTC, Chris wrote:
On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright
wrote:
Autodecode - I've suffered under that, too. The solution was
fairly simple. Append .byCodeUnit to strings
On Wednesday, 5 September 2018 at 07:48:34 UTC, Chris wrote:
On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright
wrote:
Autodecode - I've suffered under that, too. The solution was
fairly simple. Append .byCodeUnit to strings that would
otherwise autodecode. Annoying, but hardly a
On Thursday, 6 September 2018 at 07:54:09 UTC, Joakim wrote:
On Thursday, 6 September 2018 at 07:23:57 UTC, Chris wrote:
On Wednesday, 5 September 2018 at 22:00:27 UTC, H. S. Teoh
wrote:
//
Seriously, people need to get over the fantasy that they can
just use Unicode without understanding
On 06/09/2018 7:54 PM, Joakim wrote:
On Thursday, 6 September 2018 at 07:23:57 UTC, Chris wrote:
On Wednesday, 5 September 2018 at 22:00:27 UTC, H. S. Teoh wrote:
//
Seriously, people need to get over the fantasy that they can just use
Unicode without understanding how Unicode works. Most
On Thursday, 6 September 2018 at 07:23:57 UTC, Chris wrote:
On Wednesday, 5 September 2018 at 22:00:27 UTC, H. S. Teoh
wrote:
//
Seriously, people need to get over the fantasy that they can
just use Unicode without understanding how Unicode works.
Most of the time, you can get the
On Thursday, 6 September 2018 at 07:23:57 UTC, Chris wrote:
Seriously, people need to get over the fantasy that they can
just use Unicode without understanding how Unicode works.
Most of the time, you can get the illusion that it's working,
but actually 99% of the time the code is actually
On Wednesday, 5 September 2018 at 22:00:27 UTC, H. S. Teoh wrote:
//
Seriously, people need to get over the fantasy that they can
just use Unicode without understanding how Unicode works. Most
of the time, you can get the illusion that it's working, but
actually 99% of the time the code
On Wed, Sep 05, 2018 at 09:33:27PM +, aliak via Digitalmars-d wrote:
[...]
> The dstring is only ok because the 2 code units fit in a dchar right?
> But all the other ones are as expected right?
And dstring will be wrong once you have non-precomposed diacritics and
other composing sequences.
On Wednesday, 5 September 2018 at 07:48:34 UTC, Chris wrote:
On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright
wrote:
Autodecode - I've suffered under that, too. The solution was
fairly simple. Append .byCodeUnit to strings that would
otherwise autodecode. Annoying, but hardly a
On 9/4/2018 5:37 PM, bachmeier wrote:
Having to deal with the
possibility that others might have any of twelve different compiler versions
installed just isn't sustainable.
Back in the bad old DOS days, my compiler depended on the Microsoft linker,
which was helpfully included on the DOS
On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright wrote:
Autodecode - I've suffered under that, too. The solution was
fairly simple. Append .byCodeUnit to strings that would
otherwise autodecode. Annoying, but hardly a showstopper.
import std.array : array;
import std.stdio :
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote:
On 8/24/2018 6:04 AM, Chris wrote:
For about a year I've had the feeling that D is moving too
fast and going nowhere at the same time. D has to slow down
and get stable. D is past the experimental stage. Too many
people use it
On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright wrote:
On 9/1/2018 4:12 AM, Chris wrote:
Hope is usually the last thing to die. But one has to be wise
enough to see that sometimes there is nothing one can do. As
things are now, for me personally D is no longer an option,
because
On 9/4/2018 12:59 PM, Timon Gehr wrote:
[...]
Thanks for the great explanation! Not sure I thoroughly understand it, though.
Therefore, D immutable/pure are both too strong and too weak: they prevent
@system code from implementing value representations that internally use
mutation
On 9/1/2018 4:12 AM, Chris wrote:
Hope is usually the last thing to die. But one has to be wise enough to see that
sometimes there is nothing one can do. As things are now, for me personally D is
no longer an option, because of simple basic things, like autodecode, a flaw
that will be there
On 29.08.2018 22:01, Walter Bright wrote:
On 8/29/2018 10:50 AM, Timon Gehr wrote:
D const/immutable is stronger than immutability in Haskell (which is
usually _lazy_).
I know Haskell is lazy, but don't see the connection with a weaker
immutability guarantee.
In D, you can't have a lazy
On Saturday, 1 September 2018 at 21:18:27 UTC, Nick Sabalausky
(Abscissa) wrote:
On 09/01/2018 07:12 AM, Chris wrote:
Hope is usually the last thing to die. But one has to be wise
enough to see that sometimes there is nothing one can do. As
things are now, for me personally D is no longer an
On 09/01/2018 07:12 AM, Chris wrote:
Hope is usually the last thing to die. But one has to be wise enough to
see that sometimes there is nothing one can do. As things are now, for
me personally D is no longer an option, because of simple basic things,
like autodecode, a flaw that will be
On Friday, 31 August 2018 at 18:24:40 UTC, Laeeth Isharc wrote:
On Friday, 31 August 2018 at 09:37:55 UTC, Chris wrote:
On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc
wrote:
On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:
9. I hope D will be great again
Are you
On Friday, 31 August 2018 at 15:43:13 UTC, H. S. Teoh wrote:
[...]
I wasn't talking about that, but about the fact that users are
slowly but surely nudged into a certain direction. And yes, D
was advertised as a "no ideology language".
Sorry, "slowly but surely nudged" sounds very different
On Friday, 31 August 2018 at 09:37:55 UTC, Chris wrote:
On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc
wrote:
On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:
9. I hope D will be great again
Are you someone who lives by hope and fears about things that
have a
On Fri, Aug 31, 2018 at 03:13:30PM +, Chris via Digitalmars-d wrote:
> On Friday, 31 August 2018 at 14:38:36 UTC, H. S. Teoh wrote:
> > On Fri, Aug 31, 2018 at 09:37:55AM +, Chris via Digitalmars-d wrote:
> > [...]
> > > 3. moving the goal posts all the time and forcing you into a new
> >
On Friday, 31 August 2018 at 14:38:36 UTC, H. S. Teoh wrote:
On Fri, Aug 31, 2018 at 09:37:55AM +, Chris via
Digitalmars-d wrote: [...]
3. moving the goal posts all the time and forcing you into a
new paradigm every 1 1/2 years (first it was "ranges", then
"templates" and now it's
On Fri, Aug 31, 2018 at 09:37:55AM +, Chris via Digitalmars-d wrote:
[...]
> 3. moving the goal posts all the time and forcing you into a new
> paradigm every 1 1/2 years (first it was "ranges", then "templates"
> and now it's "functional", wait OOP will come back one day).
[...]
Wait, what?
On Wednesday, 29 August 2018 at 23:47:11 UTC, Laeeth Isharc wrote:
On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:
Julia is great. I don't see it as a competitor to D but for us
one way researchers might access libraries written in D. One
could do quite a lot in it, but I don't
On Thursday, 30 August 2018 at 23:03:57 UTC, Walter Bright wrote:
On 8/25/2018 4:49 PM, Nicholas Wilson wrote:
Run semantic3 on the constructor independent of the
requirement to destruct already constructed objects. If the
constructors is nothrow then there is no need to have the
destructors
On 8/25/2018 4:49 PM, Nicholas Wilson wrote:
Run semantic3 on the constructor independent of the requirement to destruct
already constructed objects. If the constructors is nothrow then there is no
need to have the destructors run or the eh code at all, because no Exceptions
can be thrown (an
On 08/29/2018 04:01 PM, Walter Bright wrote:
On 8/29/2018 10:50 AM, Timon Gehr wrote:
D const/immutable is stronger than immutability in Haskell (which is
usually _lazy_).
I know Haskell is lazy, but don't see the connection with a weaker
immutability guarantee. In any case, isn't
On 29.08.2018 21:58, Walter Bright wrote:
On 8/29/2018 11:02 AM, Timon Gehr wrote:
Absolutely. But D only strives to provide such automation in @safe
code. For @system code, we need a formal specification of what is
allowed. (And it needs to include all things that the GC and language
do; no
On Monday, 27 August 2018 at 20:15:03 UTC, Ali wrote:
On Monday, 27 August 2018 at 19:51:52 UTC, 12345swordy wrote:
On Monday, 27 August 2018 at 18:20:04 UTC, Chris wrote:
Then the D Foundation should work on it.
Easier said then done. You can't go around demanding people to
build factories
On Tuesday, 28 August 2018 at 08:51:27 UTC, Chris wrote:
On Tuesday, 28 August 2018 at 08:44:26 UTC, Chris wrote:
When people choose a programming language, there are several
boxes that have to be ticked, like for example:
- what's the future of language X? (guarantees, stability)
- how
On 8/29/2018 10:50 AM, Timon Gehr wrote:
D const/immutable is stronger than immutability in Haskell (which is usually
_lazy_).
I know Haskell is lazy, but don't see the connection with a weaker immutability
guarantee. In any case, isn't immutability a precept of FP?
On 8/29/2018 10:05 AM, Timon Gehr wrote:
This is a misunderstanding. The __mutable DIP will define the set of allowed
program rewrites based on const/immutable/pure. Then code that uses __mutable
must remain correct when they are applied. This achieves two things: it clearly
defines the
On 8/29/2018 11:02 AM, Timon Gehr wrote:
Absolutely. But D only strives to provide such automation in @safe code. For
@system code, we need a formal specification of what is allowed. (And it needs
to include all things that the GC and language do; no magic.) Note that such a
formal
On Wednesday, 29 August 2018 at 17:15:15 UTC, H. S. Teoh wrote:
Besides, this is missing the point. What I meant was that if
const could be arbitrarily overridden anywhere down the call
chain, then the compiler could no longer feasibly verify that a
particular piece of code doesn't violate
On Wed, Aug 29, 2018 at 07:02:42PM +, Dave Jones via Digitalmars-d wrote:
> On Wednesday, 29 August 2018 at 18:02:16 UTC, Timon Gehr wrote:
> > On 29.08.2018 19:15, H. S. Teoh wrote:
> > > On Wed, Aug 29, 2018 at 06:58:16PM +0200, Timon Gehr via
> > > Digitalmars-d wrote:
> > > > On 28.08.2018
On Wed, Aug 29, 2018 at 07:50:57PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 28.08.2018 03:11, Walter Bright wrote:
> > On 8/27/2018 10:08 AM, H. S. Teoh wrote:
> > > Const in D makes sense as-is. Though, granted, its infectiousness
> > > means its scope is actually very narrow, and as a
On Wednesday, 29 August 2018 at 18:02:16 UTC, Timon Gehr wrote:
On 29.08.2018 19:15, H. S. Teoh wrote:
On Wed, Aug 29, 2018 at 06:58:16PM +0200, Timon Gehr via
Digitalmars-d wrote:
On 28.08.2018 19:02, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
On 29.08.2018 19:15, H. S. Teoh wrote:
On Wed, Aug 29, 2018 at 06:58:16PM +0200, Timon Gehr via Digitalmars-d wrote:
On 28.08.2018 19:02, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via Digitalmars-d
wrote:
[...]
There are still valid use cases where const
On 28.08.2018 03:11, Walter Bright wrote:
On 8/27/2018 10:08 AM, H. S. Teoh wrote:
Const in D makes sense as-is. Though, granted, its infectiousness means
its scope is actually very narrow, and as a result, we ironically can't
use it in very many places, and so its touted benefits only rarely
On Wednesday, August 29, 2018 11:15:15 AM MDT H. S. Teoh via Digitalmars-d
wrote:
> On Wed, Aug 29, 2018 at 06:58:16PM +0200, Timon Gehr via Digitalmars-d
wrote:
> > On 28.08.2018 19:02, H. S. Teoh wrote:
> > > On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
> > > Digitalmars-d
On Wed, Aug 29, 2018 at 06:58:16PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 28.08.2018 19:02, H. S. Teoh wrote:
> > On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via Digitalmars-d
> > wrote:
> > [...]
> > > There are still valid use cases where const should be "broken".
> > >
On 29.08.2018 03:59, Walter Bright wrote:
There's been some talk of adding a "mutable" qualifier for fields, which
would stop the transitivity of const at that point. But it has problems,
such as what happens with opaque types. The compiler can no longer check
them, and hence will have to
On 28.08.2018 19:02, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via Digitalmars-d
wrote:
[...]
There are still valid use cases where const should be "broken". One of
them is mutex (another one caching). I have very little experiance in
multi-threaded
On 27.08.2018 11:14, Chris wrote:
It is unrealistic to assume that code will never break. But as I said in
my post above, dmd should give guarantees of backward compatibility of
at least N versions. Then we could be more relaxed about our code.
Each breaking change occurs between two
On Wed, Aug 29, 2018 at 01:02:54AM +, tide via Digitalmars-d wrote:
[...]
> Point being, there is a huge difference between what you were saying,
> and what you are saying now. "This data never changes" is a much
> better guarantee and check than "this code does not modify this data".
> You
On 8/26/2018 6:09 PM, Jonathan M Davis wrote:
I don't know what Walter's current plans are for what any built-in
ref-counting solution would look like, but it's my understanding that
whatever he was working on was put on hold, because he needed something like
DIP 1000 in order to make it work
H. S. Teoh wrote:
> On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote:
> [...]
> Actually, I think C++ const is not very useful, because it guarantees
> nothing. At the most, it's just a sanity checker to make sure the
> programmer didn't accidentally do something dumb. But
On Tue, 28 Aug 2018 at 19:00, Walter Bright via Digitalmars-d
wrote:
>
> There's been some talk of adding a "mutable" qualifier for fields, which would
> stop the transitivity of const at that point. But it has problems, such as
> what
> happens with opaque types. The compiler can no longer
On Tue, 28 Aug 2018 at 10:54, H. S. Teoh via Digitalmars-d
wrote:
>
> On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote:
> [...]
> > The reality is though, that D's const is not actually very useful, and
> > C++'s const is.
>
> Actually, I think C++ const is not very useful,
There's been some talk of adding a "mutable" qualifier for fields, which would
stop the transitivity of const at that point. But it has problems, such as what
happens with opaque types. The compiler can no longer check them, and hence will
have to assume they contain mutable members.
Thanks, that's a good explanation of the point of the differences between const
and immutable.
On Tuesday, 28 August 2018 at 20:32:29 UTC, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 07:39:20PM +, tide via
Digitalmars-d wrote:
On Tuesday, 28 August 2018 at 17:02:46 UTC, H. S. Teoh wrote:
> On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
> Digitalmars-d wrote: [...]
> >
On Tue, Aug 28, 2018 at 06:44:37PM +, aliak via Digitalmars-d wrote:
> On Tuesday, 28 August 2018 at 17:53:36 UTC, H. S. Teoh wrote:
> > On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via
> > > D has no way to express head-const, and it turns out it's a
> > > tremendously useful concept.
> >
On Tue, Aug 28, 2018 at 07:39:20PM +, tide via Digitalmars-d wrote:
> On Tuesday, 28 August 2018 at 17:02:46 UTC, H. S. Teoh wrote:
> > On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
> > Digitalmars-d wrote: [...]
> > > There are still valid use cases where const should be
On Tuesday, 28 August 2018 at 17:02:46 UTC, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
Digitalmars-d wrote: [...]
There are still valid use cases where const should be
"broken". One of them is mutex (another one caching). I have
very little experiance in
On Tuesday, 28 August 2018 at 17:53:36 UTC, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via
D has no way to express head-const, and it turns out it's a
tremendously useful concept.
I can live without head-const... but what *really* makes const
painful for me is the lack
On Tue, Aug 28, 2018 at 10:20:06AM -0700, Manu via Digitalmars-d wrote:
[...]
> The reality is though, that D's const is not actually very useful, and
> C++'s const is.
Actually, I think C++ const is not very useful, because it guarantees
nothing. At the most, it's just a sanity checker to make
On Tue, 28 Aug 2018 at 00:55, Walter Bright via Digitalmars-d
wrote:
>
> On 8/26/2018 11:16 PM, Manu wrote:
> >> The code looks the same, and in fact, is about 98% the same.
> > This code appears to be a mechanical translation.
>
> It's not. It's by hand. But I had a specific goal of minimizing
On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via Digitalmars-d
wrote:
[...]
> There are still valid use cases where const should be "broken". One of
> them is mutex (another one caching). I have very little experiance in
> multi-threaded programming, but what do you think about
On Mon, Aug 27, 2018 at 06:11:14PM -0700, Walter Bright via Digitalmars-d wrote:
> On 8/27/2018 10:08 AM, H. S. Teoh wrote:
> > Const in D makes sense as-is. Though, granted, its infectiousness means
> > its scope is actually very narrow, and as a result, we ironically
> > can't use it in very
On Tuesday, 28 August 2018 at 08:44:26 UTC, Chris wrote:
Last but not least, if it's true that the D Foundation has
raised only 3.2K, then there's something seriously wrong.
The Foundation has significantly more than 3.2k. The Open
Collective account is relatively new and is but one
On Tuesday, 28 August 2018 at 08:44:26 UTC, Chris wrote:
When people choose a programming language, there are several
boxes that have to be ticked, like for example:
- what's the future of language X? (guarantees, stability)
- how easy is it to get going (from "Hello world" to a complete
On Tuesday, 28 August 2018 at 07:30:01 UTC, Walter Bright wrote:
On 8/27/2018 2:14 AM, Chris wrote:
bad feeling about the way things are going atm.
I can quote you a lng list of problems that are obvious
only in hindsight, by world leading development teams.
Start by watching the
On Tuesday, 28 August 2018 at 07:53:34 UTC, Walter Bright wrote:
Let's take the much-maligned D const. It isn't C++ const (let's
call that "head-const", because that's what it is). Head-const
for a function parameter tells us very little about what may
happen to it in the function. You can
On 8/26/2018 11:16 PM, Manu wrote:
The code looks the same, and in fact, is about 98% the same.
This code appears to be a mechanical translation.
It's not. It's by hand. But I had a specific goal of minimizing the diffs, so
that if the translation didn't work, it reduced the number of places
On 8/27/2018 2:14 AM, Chris wrote:
On Sunday, 26 August 2018 at 22:44:05 UTC, Walter Bright wrote:
Because nobody thought about that issue before. A lot of things only become
apparent in hindsight.
QED. With this approach you do more harm than good. I have a bad feeling about
the way things
On Tuesday, 28 August 2018 at 01:11:14 UTC, Walter Bright wrote:
On 8/27/2018 10:08 AM, H. S. Teoh wrote:
Const in D makes sense as-is. Though, granted, its
infectiousness means
its scope is actually very narrow, and as a result, we
ironically can't
use it in very many places, and so its
On 8/27/2018 10:08 AM, H. S. Teoh wrote:
Const in D makes sense as-is. Though, granted, its infectiousness means
its scope is actually very narrow, and as a result, we ironically can't
use it in very many places, and so its touted benefits only rarely
apply. :-( Which also means that it's
1 - 100 of 242 matches
Mail list logo
