On 10/22/2018 1:34 AM, Manu wrote:
I posted it, twice... 2 messages, back to back, and you're responding
to this one, and not that one. I'll post it again...
Posting it over and over is illustrative of the failure of posting proposal
documents to the n.g. instead of posting it as a DIP which
On 10/22/2018 1:42 AM, Manu wrote:
You removed whatever comment you're referring to.
If your newsreader cannot find the antecedent, you badly need to use a better
one. Thunderbird handles this rather well, there's no reason to use an inferior one.
Or just click the <- button:
https://digita
On 10/21/2018 11:58 AM, Timon Gehr wrote:
[...]
Thank you, Timon, for a nice explanation of what I was trying to express.
On 10/21/2018 5:54 PM, Manu wrote:
Would you please respond to my messages, and specifically, respond to
the code that I presented to you in response to your broken example.
Or any of my earlier fragments throughout this thread. I've shared
quite a few, and so far, nobody has ever produced a crit
On 10/21/2018 4:12 PM, Nicholas Wilson wrote:
On Sunday, 21 October 2018 at 21:32:14 UTC, Walter Bright wrote:
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other direction,
On 10/21/2018 2:08 PM, Walter Bright wrote:
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other direction, which is not part of the proposal.
It's Manu's example.
Then I don't know what the proposal is. Pieces of it
On 10/21/2018 12:20 PM, Nicholas Wilson wrote:
Yes, but the problem you describe is arises from implicit conversion in the
other direction, which is not part of the proposal.
It's Manu's example.
I'd like to add that if the compiler can prove that a T* points to a unique T,
then it can be implicitly cast to shared(T)*. And it does so, like the result of
.dup can be so converted.
On 10/20/2018 11:08 AM, Nicholas Wilson wrote:
You can if no-one else writes to it, which is the whole point of Manu's
proposal. Perhaps it should be const shared instead of shared but still.
There is no purpose whatsoever to data that can be neither read nor written.
Shared data is only usefu
On 10/20/2018 11:24 AM, Manu wrote:
This is an unfair dismissal.
It has nothing at all to do with fairness. It is about what the type system
guarantees in @safe code. To repeat, the current type system guarantees in @safe
code that T* and shared(T)* do not point to the same memory location.
On 10/20/2018 11:30 AM, Manu wrote:
You can write an invalid program in any imaginable number of ways;
that's just not an interesting discussion.
What we're discussing is not an invalid program, but what guarantees the type
system can provide.
D's current type system guarantees that a T* and
On 10/19/2018 11:18 PM, Manu wrote:
The reason I ask is because, by my definition, if you have:
int* a;
shared(int)* b = a;
While you have 2 numbers that address the same data, it is not actually aliased
because only `a` can access it.
They are aliased, by code that believes it is unshared, a
On 10/17/2018 12:20 AM, Manu wrote:
What does it mean 'aliased' precisely?
Aliasing means there are two paths to the same piece of data. That could be two
pointers pointing to the same data, or one pointer to a variable that is
accessible by name.
It doesn't really give us
anything in prac
On 10/17/2018 4:29 AM, jmh530 wrote:
Isn't that also true for isolated data (data that only allows one alias)?
That's colloquially called "unique" data. And yes, it is also true for that.
That's why casting the return value of malloc() to 'shared' is safe. It's just
that the language has no w
On 10/15/2018 11:46 AM, Manu wrote:
[...]
Shared has one incredibly valuable feature - it allows you, the programmer, to
identify data that can be accessed by multiple threads. There are so many ways
that data can be shared, the only way to comprehend what is going on is to build
a wall arou
On 10/16/2018 1:16 PM, notna wrote:
[...]
We're not going to automatically close stale pull requests, nor are we going to
arbitrarily close old unfixed bug reports.
On 10/4/2018 6:15 AM, Shachar Shemesh wrote:
One of those things is this: October 14th will be my last day working for
Weka.IO.
My best wishes for your next adventure! -Walter
On 10/3/2018 1:33 AM, Atila Neves wrote:
I'm confused. Given how the lifetimes of aggregates are defined in DIP1000, and
also given that I tried to escape members of a struct when I wrote fearless and
the compiler didn't let me, I'm trying to understand in what situation scope
doesn't apply tra
On 10/2/2018 4:30 PM, Adam D. Ruppe wrote:
On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote:
Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved structs
in a number of situations - e.g. when the return value was an rvalue.
Something like
Eh, I don't think
On 10/2/2018 1:49 PM, Manu wrote:
So... `scope` says "I won't escape this, but I may escape anything
this points to"?
That's right.
http://dconf.org/2017/talks/bright.html
On 10/2/2018 2:17 AM, Walter Bright wrote:
1. Don't allow moving of C++ structs
2. Add a struct attribute that means "not moveable"
3. DIP 1014, which is add a __move_post_blit() function (most complex solution)
4. Use copy/destruct for C++ structs that have copy constructors (this is the
old C+
On 9/29/2018 9:34 PM, Manu wrote:
Who knows about DIP 1014? (struct move hook)
Is it well received? Is it likely to be accepted soon?
I'm working on the std::string binding, it's almost finished... but
then I hit a brick wall.
GNU's std::string implementation stores an interior pointer! >_<
T
On 9/29/2018 9:34 PM, Manu wrote:
Who knows about DIP 1014? (struct move hook)
When discussing DIP 1014, a link is helpful:
https://github.com/dlang/DIPs/blob/38cec74a7471735559e3b8a7553f55102d289d28/DIPs/DIP1014.md
On 10/1/2018 7:31 PM, Manu wrote:
Surely `scope` must be transitive?
It isn't.
How could it work otherwise?
It's a storage class, not a type constructor. There is no "pointer to scope"
type, for example. Having it transitive would make it unworkable, actually, for
similar reasons that tra
On 10/1/2018 4:56 PM, Timon Gehr wrote:
There was no 'scope' in the OP, and no, that is not sufficient either, because
scope is not transitive but shared is.
Oops, I missed that point. Glad you noticed it.
On 9/29/2018 9:34 PM, Manu wrote:
GNU's std::string implementation stores an interior pointer! >_<
No other implementation does this. It's a really bad implementation
actually, quite inefficient. It could make better use of its space for
small-strings if it wasn't wasting 8-bytes for an interior
On 9/27/2018 11:33 AM, Timon Gehr wrote:
The current behavior is easy to specify and simple to implement, and it is what
Walter has implemented. A better behavior that is almost as simple to implement
would be to insert nested functions into the symbol table in blocks of
back-to-back-defined ne
On 9/27/2018 12:35 AM, aliak wrote:
Anyway, on a related note: D itself (not identifiers, but std) also supports
unicode 6 or something. That's from 2010. That's a decade ago. We're at unicode
11 now. And I've already had someone tell me (while trying to get them to use D)
- "hold on it support
On 9/26/2018 5:46 AM, Steven Schveighoffer wrote:
Does this need a DIP?
Feel free to write one, but its chances of getting incorporated are remote and
would require a pretty strong rationale that I haven't seen yet.
On 9/26/2018 5:46 AM, Steven Schveighoffer wrote:
This is a non-starter. We can't break people's code, especially for trivial
reasons like 'you shouldn't code that way because others don't like it'. I'm
pretty sure Walter would be against removing Unicode support for identifiers.
We're not goi
On 9/25/2018 11:50 PM, Shachar Shemesh wrote:
This sounded like a very compelling example, until I gave it a second thought. I
now fail to see how this example translates to a real-life scenario.
Also, there are usually common ASCII versions of city names, such as Cologne for
Köln.
On 9/25/2018 1:49 AM, Chris wrote:
This said, I was working with a blind person a couple of years ago (I think it
was 3 years ago) and he used D for one of his assignments, he never had a
problem with the documentation.
That's good to hear.
On 9/23/2018 12:06 PM, Abdulhaq wrote:
The early history of computer science is completely dominated by cultures who
use latin script based characters,
Small character sets are much more implementable on primitive systems like
telegraphs and electro-mechanical ttys.
It wasn't even practical
On 9/23/2018 3:23 PM, Neia Neutuladh wrote:
Okay, that's why you previously selected C99 as the standard for what characters
to allow. Do you want to update to match C11? It's been out for the better part
of a decade, after all.
I wasn't aware it changed in C11.
On 9/23/2018 6:06 PM, Dennis wrote:
Have you changed your mind since?
D the language is well suited to the development of Unicode apps. D source code
is another matter.
I met a blind programmer at a conference back in the 80's, and had a long talk
with her and how she did it. I was amazed. Ever since, I've wanted to ensure
products I've worked on were accessible to the blind.
It's one thing to follow guidelines, it's another to have someone who relies on
a sc
On 9/22/2018 6:01 PM, Jonathan M Davis wrote:
For better or worse, English is the international language of science and
engineering, and that includes programming.
In the earlier days of D, I put on the web pages a google widget what would
automatically translate the page into any language googl
On 9/23/2018 9:52 AM, aliak wrote:
Not seeing identifiers in languages you don't program in or can read in is
expected.
On the other hand, I've been programming for 40 years. I've customized my C++
compiler to emit error messages in various languages:
https://github.com/DigitalMars/Compiler/
On 9/21/2018 7:46 AM, Steven Schveighoffer wrote:
I can see the marketing now, "D finds infinite loops in compile-time code way
faster than Jai!".
We need you over in marketing!
When I originally started with D, I thought non-ASCII identifiers with Unicode
was a good idea. I've since slowly become less and less enthusiastic about it.
First off, D source text simply must (and does) fully support Unicode in
comments, characters, and string literals. That's not an issue.
On 9/21/2018 9:29 AM, welkam wrote:
Jai compiler perform parsing and lexing in different thread so its kinda multi
threaded. Its possible to do the same with D front end. We can start here but
there are plenty of low hanging fruits in compiler you just need to run profiler
to find them
D was
On 9/21/2018 12:19 AM, mate wrote:
It depends on the developer not doing anything stupid
Aye, there's the rub!
On 9/20/2018 10:11 PM, mate wrote:
Note that the build can be done at compile time because the metaprogramming
capabilities of the language are not limited in terms of system calls.
Back in the naive olden days, Microsoft released ActiveX, where a web page could
load executable objects (!) fro
I've learned this the hard way, and I've had to learn it several times because I
am a slow learner. I've posted this before, and repeat it because bears repeating.
The procedure is:
1. pass the test suite
2. prep the file for conversion, i.e. try to minimize the use of idioms that
won't easily
On 9/20/2018 7:44 PM, Nick Sabalausky (Abscissa) wrote:
3. You can embed your buildscript into one of your project's existing source
files, instead of putting it in a dedicated buildscript file.
(We can do that in D too, by utilizing version identifiers, but we don't because
its messy and most
On 9/18/2018 5:22 PM, Manu wrote:
Thank you Walter for coming to the party!
I suppose I should explain this.
1. The PR uses a different syntax, i.e. strings instead of identifiers. This
implies it is not creating a scope, and doesn't interfere with the scoping of
the existing syntax. The des
On 9/19/2018 11:35 AM, Steven Schveighoffer wrote:
I'm running into this coincidentally right now, when trying to debug a PR. I
found I'm getting a range error deep inside a phobos function. But because
Phobos is trying to be pure @nogc nothrow @safe, I can do almost nothing to
display what is
On 9/19/2018 10:13 AM, Shachar Shemesh wrote:
assert(condition, string); // string is useless without actual info about
what went wrong.
assert(condition, format(string, arg, arg)); // No good - format is not @nogc
Another method:
debug
assert(condition, format(string, arg, arg));
On 9/7/2018 10:35 AM, Eugene Wissner wrote:
fill() uses enforce() which allocates and throws.
The addition of -dip1008 stopped using the gc for throwing exceptions, but it's
opt-in at the moment.
On 8/22/2018 10:37 PM, Shachar Shemesh wrote:
Let's start with this one:
https://issues.dlang.org/show_bug.cgi?id=14246#c6
https://github.com/dlang/dmd/pull/8697
On 9/8/2018 9:37 PM, Josphe Brigmo wrote:
[...]s**t[...]
We expect professional demeanor here. Please don't use such language.
On 9/8/2018 4:29 AM, Josphe Brigmo wrote:
Um, I didn't say don't use Git!
I've done this manually before git. I can guarantee you that the dates put in
the file are invariably wrong, incomplete, or non-existent.
But if you bring up a source file in github, and click on the "Blame" button,
i
On 9/5/2018 4:55 PM, Timon Gehr wrote:
John rather explicitly states the opposite in
the article.
I believe that his statement:
"it’s not an interpretation that is universally useful"
is much weaker than saying "the opposite". He did not say it was "never useful".
For example, it is not univ
On 9/4/2018 10:16 PM, Manu wrote:
I'm serious, you can have your cake, and potentially, I could have my
cake too, and everybody would be happy... nobody would be sad.
If it is the same, I provided solutions in those threads. The incomplete example
code did not make use of them.
I don't know
On 9/2/2018 2:12 PM, Nick Sabalausky (Abscissa) wrote:
On 09/01/2018 04:15 PM, Walter Bright wrote:
https://blog.regehr.org/archives/1091
This does make me think of one thing: Shouldn't assert expressions be required
to be pure? (even if only weakly pure)
Not sure how much practical proble
On 9/4/2018 10:32 PM, Manu wrote:
"A handwavy description"!
What do you mean? I started the email with the code... if you compiled
it you would have reproduced those error messages.
There are 3 files referenced, but only two are given.
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 dist
On 9/4/2018 5:31 PM, Manu wrote:
I'm just showing one case that you tend to be confronted with
immediately, which is that if you import a module, and then open a
namespace with the same name as the root namespace of a module you
imported, that is an error condition; the namespace conflicts with t
On 9/4/2018 3:33 PM, Manu wrote:
file1.d
-
module bliz.ecs.component_access;
import bliz.ecs.table;
import bliz.ecs.types;
extern(C++, bliz):
// things...
Error: project\ecs\include\d2\bliz\ecs\component_access.d(7): Error:
namespace `bliz.ecs.component_access.bliz` conflicts with import
Another example I read on HackerNews today:
"I recall that during their most recent s3 outage Amazon's status page was green
across the board, because somehow all the assets that were supposed to be
displayed when things went wrong were themselves hosted on the thing that was down."
https://n
On 9/3/2018 11:55 AM, Joakim wrote:
On Monday, 3 September 2018 at 16:55:10 UTC, Jonathan M Davis wrote:
But if you're ever expecting IDE support to be a top priority of many of the
contributors, then you're going to be sorely disappointed. It's the sort of
thing that we care about because we c
https://issues.dlang.org/show_bug.cgi?id=19221
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 (therefor
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 for
On 9/3/2018 7:19 PM, Laeeth Isharc wrote:
The way for D to appeal to more people is not to address
the complaints of those who spend more time writing on the forum grumbling but
don't use it much, because in my experience you do much better appealing to the
people who are your best customers th
On 9/3/2018 8:33 AM, tide wrote:
Yes why wouldn't a company want to fix a "feature" where by, if you have a
scratch on a DVD you have to go buy another one in order to play it.
Not playing it with an appropriate message is fine. Hanging the machine is not.
It's obviously not that big of a dea
On 9/1/2018 8:18 PM, Nick Sabalausky (Abscissa) wrote:
[...]
My take on all this is people spend 5 minutes thinking about it and are
confident they know it all.
A few years back some hacker claimed they'd gotten into the Boeing flight
control computers via the passenger entertainment system
On 9/1/2018 5:47 PM, Nick Sabalausky (Abscissa) wrote:
All in all, John is very non-committal about the whole thing.
He probably got tired of arguing about it :-)
On 9/1/2018 3:23 PM, Guillaume Boucher wrote:
On Saturday, 1 September 2018 at 20:15:15 UTC, Walter Bright wrote:
Note the "may or may not be evaluated." We've debated this here before. I'm
rather pleased that John agrees with me on this.
I.e. the optimizer can assume the expression is true an
On 9/1/2018 3:58 PM, Adam D. Ruppe wrote:
On Saturday, 1 September 2018 at 22:10:27 UTC, Nick Sabalausky wrote:
I've used StackOverflow. It's NOT a place for asking and answering questions.
I generally agree, but the D tag on it isn't so bad since most the annoying
regulars keep away. It is m
On 9/1/2018 2:33 PM, Gambler wrote:
Alan Kay, Joe Armstrong, Jim Coplien - just to name a few famous people
who talked about this issue. It's amazing that so many engineers still
don't get it. I'm inclined to put some blame on the recent TDD movement.
They often to seem stress low-level code perf
On 9/1/2018 5:33 AM, tide wrote:
It is vastly different, do you know what fly by wire is?
Yes, I do. Do you know I worked for three years on critical flight controls
systems at Boeing? I said so in the article(s). These ideas are not mine, I did
not come up with them in 5 minutes at the keybo
On 9/1/2018 5:25 AM, tide wrote:
and that all bugs can be solved with asserts
I never said that, not even close.
But I will maintain that DVD players still hanging on a scratched DVD after 20
years of development means there's some cowboy engineering going on, and an
obvious lack of concern
On 9/1/2018 1:18 AM, Walter Bright wrote:
On 8/31/2018 7:28 PM, tide wrote:
I'm just wondering but how would you code an assert to ensure the variable for
a title bar is the correct color? Just how many asserts are you going to have
in your real-time game that can be expected to run at 144+ fps
On 8/31/2018 3:16 AM, Andrey wrote:
Forum posts should be informative and contain meaningful text that will be
understandable for readers. And if required, it should contain videos / images /
screenshots / quotes / links, etc.
It already highlights quotes and links. As for the rest, the D foru
https://blog.regehr.org/archives/1091
As usual, John nails it in a particularly well-written essay.
"ASSERT(expr)
Asserts that an expression is true. The expression may or may not be evaluated.
If the expression is true, execution continues normally.
If the expression is false, what happens is u
On 9/1/2018 3:49 AM, Dennis wrote:
On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote:
For example, in any CS program, are there any courses at all about this?
In Year 1 Q4 of my Bachelor CS, there was a course "Software Testing and Quality
Engineering" which covered things like t
On 9/1/2018 2:15 AM, Paulo Pinto wrote:
On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright wrote:
On 8/31/2018 11:59 PM, Paulo Pinto wrote:
For example, in any CS program, are there any courses at all about this?
Yes, we had them on my degree,
I'm curious how the courses you took c
On 8/31/2018 7:28 PM, tide wrote:
I'm just wondering but how would you code an assert to ensure the variable for a
title bar is the correct color? Just how many asserts are you going to have in
your real-time game that can be expected to run at 144+ fps ?
Experience will guide you on where to
On 8/31/2018 11:59 PM, Paulo Pinto wrote:
For example, in any CS program, are there any courses at all about this?
Yes, we had them on my degree,
I'm curious how the courses you took compared with the articles I wrote about
it.
On 8/31/2018 5:47 PM, tide wrote:
I've already read them before. Why don't you explain what is wrong with it
rather than posting articles.
Because the articles explain the issues at length. Explaining why your proposal
is deeply flawed was the entire purpose I wrote them.
You are just takin
On 8/31/2018 5:40 PM, tide wrote:
On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:
On 8/31/2018 2:40 PM, tide wrote:
I don't think I've ever had a **game** hung up in a black screen and not be
able to close it.
I've had that problem with every **DVD player** I've had in the las
On 8/31/2018 2:40 PM, tide wrote:
I don't think I've ever had a game hung up in a black
screen and not be able to close it.
I've had that problem with every DVD player I've had in the last 20 years. Power
cycling is the only fix.
On 8/31/2018 2:21 PM, tide wrote:
On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:
"Stopping all executing may not be the correct 'safe state' for an airplane
though!"
Depends on the aircraft and how it is implemented. If you have a plane that is
fly by wire, and you stop all exe
On 8/31/2018 1:42 PM, Paulo Pinto wrote:
Some countries do have engineering certifications and professional permits for
software engineering, but its still a minority.
That won't fix anything, because there is NO conventional wisdom in software
engineering for how to deal with program bugs. I
https://news.ycombinator.com/item?id=17880722
Typical comments:
"`assertAndContinue` crashes in dev and logs an error and keeps going in prod.
Each time we want to verify a runtime assumption, we decide which type of assert
to use. We prefer `assertAndContinue` (and I push for it in code revie
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 E
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 semanti
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 specificatio
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 wit
On 8/28/2018 10:18 PM, Nicholas Wilson wrote:
Bugzilla is not documentation. These are language changes they need to be in
release notes and the spec.
You asked for a clue: "we have no clue WTF its supposed to do or why the changes
are being made" and there it is. There are no barriers to revi
On 8/28/2018 11:52 PM, Jonathan M Davis wrote:
Would it make sense then to change it to work more like what you and Martin
were thinking of doing?
Yes, it would. But it would be a non-trivial effort to remove Kenji's design.
On 8/28/2018 6:39 AM, Iain Buclaw wrote:
Template emission strategy is a mess, we're better off just instantiating all
templates in all compilation units, and let the compiler decide whatever to
discard. Even -allinst does not instantiate enough to allow the compiler to make
such decisions that
On 8/23/2018 6:10 AM, Atila Neves wrote:
--
struct S {
int x;
@safe int* foo() { return &x; }
}
--
% dmd -o- -dip1000 foo.d
% echo $?
0
struct S {
int x;
@safe int* foo() { return &x; }
}
int* bar() {
S s;
return s.foo();
}
dmd test -dip1000
test.d(3
On 8/28/2018 6:12 AM, Steven Schveighoffer wrote:
So this would mean a member function would have to be refactored into a
different function with a different calling syntax. i.e:
x.foo(target);
would have to be refactored to:
target.foo(x);
or foo(target, x);
Maybe it should be anyway.
B
On 8/25/2018 4:09 AM, Nicholas Wilson wrote:
On Saturday, 25 August 2018 at 02:25:41 UTC, Walter Bright wrote:
I'm not hostile to debate. I just don't care for "this is uncharted territory,
so let's do nothing" which has been going on for probably 4 years now,
coincident with "scope is incomple
On 8/25/2018 5:42 AM, Chris M. wrote:
What about my other point then on the syntax? I think something similar to what
I suggested would be a much more flexible solution and is worth considering.
Much more work would be needed to make that a proposal.
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.
1 - 100 of 5061 matches
Mail list logo