https://issues.dlang.org/show_bug.cgi?id=16538
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
|--- |FIXED
--- Comment #3 from Dlang Bot ---
dlang/dmd pull request #14016 "fix Issue 23034 - importC: head-const struct
confused with multiple f…" was merged into master:
- 62c0846dd48cef8cf032a552c3e43c18565c42ea by Walter Bright:
fix Issue 23034 - importC: head-const struc
https://issues.dlang.org/show_bug.cgi?id=23034
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
---
@WalterBright created dlang/dmd pull request #14016 "fix Issue 23034 - importC:
head-const struct confused with multiple f…" fixing this issue:
- fix Issue 23034 - importC: head-const struct confused with multiple files on
command line
https://github.com/dlang/dmd/pull/14016
--
https://issues.dlang.org/show_bug.cgi?id=23034
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1
https://issues.dlang.org/show_bug.cgi?id=23034
Issue ID: 23034
Summary: importC: head-const struct confused with multiple
files on command line
Product: D
Version: D2
Hardware: All
OS: All
Status
https://issues.dlang.org/show_bug.cgi?id=16538
--- Comment #2 from Walter Bright ---
Fixed by https://github.com/dlang/dmd/pull/6731
--
https://issues.dlang.org/show_bug.cgi?id=16538
Walter Bright changed:
What|Removed |Added
CC|
https://issues.dlang.org/show_bug.cgi?id=13796
--- Comment #2 from github-bugzi...@puremagic.com ---
Commit pushed to stable at https://github.com/dlang/phobos
https://github.com/dlang/phobos/commit/415d573a3c8688396f0f46643bd1fedc923620dc
Add std.experimental.typecons.HeadConst - fix issue
https://issues.dlang.org/show_bug.cgi?id=16538
Issue ID: 16538
Summary: Parameter head-const-ness shouldn't matter but does
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity
https://issues.dlang.org/show_bug.cgi?id=13796
--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos
https://github.com/dlang/phobos/commit/415d573a3c8688396f0f46643bd1fedc923620dc
Add std.experimental.typecons.HeadConst - fix issue
https://issues.dlang.org/show_bug.cgi?id=13796
github-bugzi...@puremagic.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wednesday, 24 February 2016 at 19:28:28 UTC, extrawurst wrote:
On Wednesday, 24 February 2016 at 09:57:51 UTC, Atila Neves
wrote:
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright
wrote:
[...]
I think that increasing language complexity for the sake of
C++ integration is a
On Wednesday, 24 February 2016 at 09:57:51 UTC, Atila Neves wrote:
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright
wrote:
rears its head again :-)
Head Const is what C++ has for const, i.e. it is not
transitive, applies to one level only. D has transitive const.
What head const
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote:
rears its head again :-)
Head Const is what C++ has for const, i.e. it is not
transitive, applies to one level only. D has transitive const.
What head const will do for us:
1. make it easy to interface to C++ code that uses
On Friday, 19 February 2016 at 21:53:16 UTC, Walter Bright wrote:
On 2/19/2016 4:38 AM, Jonathan M Davis wrote:
Why not? I would expect the opaque type to have to have it
too, e.g.
@mutable struct S;
That would mean you're proposing '@mutable const' as a type
constructor, which you'd
On Friday, 19 February 2016 at 06:39:53 UTC, Walter Bright wrote:
Allow @mutable, and no more mechanical checking in D. Recall
that D supports opaque types, meaning types are not fully known
to the compiler.
Allow @trusted, an no more mechanical checking in D. Recall that
D supports extern
On Friday, 19 February 2016 at 00:45:00 UTC, Walter Bright wrote:
On 2/18/2016 6:04 AM, Marc Schütz wrote:
Rule 2 only forbids _static immutables_ with @mutable members,
precisely because
those could end up in read-only memory. I don't see how
allocators are affected
at all. An allocator would
On Friday, 19 February 2016 at 21:53:16 UTC, Walter Bright wrote:
On 2/19/2016 4:38 AM, Jonathan M Davis wrote:
Yes, as long as you have the source code, finding @trusted
violations is _way_
easier in D than it is in C++, but the fact that it's possible
to cast away
const and mutate still
On 02/19/2016 05:04 PM, Chris Wright wrote:
In other words, it works fine if you have a ref-counted string. It works
fine if you have a ref-counted list of ref-counted strings. But that list
*must* be mutable.
Much simpler - direct membership. The first thing people want to do when
you give
On Fri, 19 Feb 2016 16:09:21 -0500, Andrei Alexandrescu wrote:
> On 02/19/2016 03:46 PM, Iakh wrote:
>> On Thursday, 18 February 2016 at 22:46:04 UTC, Walter Bright wrote:
>>> On 2/18/2016 10:22 AM, Timon Gehr wrote:
He wanted to embed a mutable reference count literally within a const
On 2/19/2016 4:38 AM, Jonathan M Davis wrote:
Yes, as long as you have the source code, finding @trusted violations is _way_
easier in D than it is in C++, but the fact that it's possible to cast away
const and mutate still means that the compiler can't actually guarantee that an
object is not
On 02/19/2016 03:46 PM, Iakh wrote:
On Thursday, 18 February 2016 at 22:46:04 UTC, Walter Bright wrote:
On 2/18/2016 10:22 AM, Timon Gehr wrote:
He wanted to embed a mutable reference count literally within a const
object.
Not a headconst object.
I know. I pointed out how it could be done in
On Thursday, 18 February 2016 at 22:46:04 UTC, Walter Bright
wrote:
On 2/18/2016 10:22 AM, Timon Gehr wrote:
He wanted to embed a mutable reference count literally within
a const object.
Not a headconst object.
I know. I pointed out how it could be done in a way to achieve
the same effect.
On Friday, 19 February 2016 at 12:03:01 UTC, Walter Bright wrote:
On 2/19/2016 3:21 AM, Jonathan M Davis wrote:
D is definitely in a better boat in that it's easier to find
and catch problems
with const, but it really doesn't do much more to actually
guarantee that a
const object isn't being
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote:
1. make it easy to interface to C++ code that uses const, as
currently it is not very practical to do so, you have to resort
to pragma(mangle)
If it's for mangling, there can be lightweight pragma for
individual parameters:
On 2/19/2016 3:21 AM, Jonathan M Davis wrote:
D is definitely in a better boat in that it's easier to find and catch problems
with const, but it really doesn't do much more to actually guarantee that a
const object isn't being violated. Programmers are free to do horrible things
and mark it as
On Friday, 19 February 2016 at 10:03:44 UTC, Walter Bright wrote:
On 2/18/2016 11:46 PM, Jonathan M Davis wrote:
We're in exactly the same boat as C++ in that we rely on the
programmer to be smart about casting away const in order for
const to provide
any guarantees.
No, we're not. @trusted
On 2/18/2016 11:46 PM, Jonathan M Davis wrote:
We're in exactly the same boat as C++ in that we rely on the
programmer to be smart about casting away const in order for const to provide
any guarantees.
No, we're not. @trusted is specifically designed to be greppable (so are casts,
by the
On Friday, 19 February 2016 at 08:51:26 UTC, Shachar Shemesh
wrote:
The way I see it, here's how it is with C++:
Get const pointer. Cast away its constness. If the original
data was mutable, you're gold. If not, undefined behaviour.
Yes, and since interpret_cast<> seems to not accept casting
On 17/02/16 14:03, Jakob Ovrum wrote:
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote:
rears its head again :-)
Head Const is what C++ has for const, i.e. it is not transitive,
applies to one level only. D has transitive const.
What head const will do for us:
1. make it easy
On Friday, 19 February 2016 at 06:39:53 UTC, Walter Bright wrote:
On 2/18/2016 9:46 PM, Jonathan M Davis wrote:
On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright
wrote:
On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
headconst may solve the extern(C++) problem, but it really
doesn't
On 2/18/2016 9:46 PM, Jonathan M Davis wrote:
On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright wrote:
On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
headconst may solve the extern(C++) problem, but it really doesn't solve the
problems we have with const.
'mutable' doesn't really
On Friday, 19 February 2016 at 05:33:54 UTC, Doc wrote:
On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis
wrote:
The more I look at it, the more I'm inclined to think that
introducing @mutable for member variables with a
corresponding, required attribute on the struct or
On Thursday, 18 February 2016 at 22:40:32 UTC, Walter Bright
wrote:
On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
headconst may solve the extern(C++) problem, but it really
doesn't solve the
problems we have with const.
'mutable' doesn't really solve a problem, it just means that
C++
On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis
wrote:
The more I look at it, the more I'm inclined to think that
introducing @mutable for member variables with a corresponding,
required attribute on the struct or class it's in (e.g.
@has_mutable) is really what we need to
On 2/18/2016 6:04 AM, Marc Schütz wrote:
Rule 2 only forbids _static immutables_ with @mutable members, precisely because
those could end up in read-only memory. I don't see how allocators are affected
at all. An allocator would be mutable, or at least manage mutable memory.
You could create a
On Thursday, 18 February 2016 at 22:48:01 UTC, Walter Bright
wrote:
struct A { int* pi; }
and *pi will be mutable even though pi is __const.
Here's the big deal: when you have started on an implementation
with constness in, and then evolve the codebase and have to turn
some fields mutable
On 2/18/2016 4:18 AM, Andrei Alexandrescu wrote:
On 02/17/2016 05:44 PM, Walter Bright wrote:
It would seem that implementing headconst as a type constructor would
let people who wanted mutable members have their way, without
introducing backdoors in const.
Doesn't seem that way to me, viz:
On 2/18/2016 10:22 AM, Timon Gehr wrote:
He wanted to embed a mutable reference count literally within a const object.
Not a headconst object.
I know. I pointed out how it could be done in a way to achieve the same effect.
BTW, shared_ptr<> uses a pointer to the ref count.
On 2/18/2016 4:16 AM, Jonathan M Davis wrote:
headconst may solve the extern(C++) problem, but it really doesn't solve the
problems we have with const.
'mutable' doesn't really solve a problem, it just means that C++ 'const' is a
documentation aid, not a guarantee.
On 18.02.2016 13:03, Walter Bright wrote:
On 2/18/2016 2:47 AM, Timon Gehr wrote:
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable reference count within a const
On Thursday, 18 February 2016 at 14:58:00 UTC, ixid wrote:
On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis
wrote:
The problem that folks frequently want to be able to solve that
they simply cannot solve >with D's const (and headconst
wouldn't help) is that they want to be able
On Thursday, 18 February 2016 at 14:58:00 UTC, ixid wrote:
Is it not possible to have two objects, the data and the
information about the data? It seems like a mistake to try to
Not if the immutability is transitive. But "struct" isn't really
an object, it is a chunk of memory. Often an
On Thursday, 18 February 2016 at 11:57:59 UTC, Jonathan M Davis
wrote:
The problem that folks frequently want to be able to solve that
they simply cannot solve >with D's const (and headconst wouldn't
help) is that they want to be able to pass an object >to a
function that takes it as const or
On Thursday, 18 February 2016 at 11:12:40 UTC, Dicebot wrote:
On 02/17/2016 08:48 PM, Marc Schütz wrote:
On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote:
One example of a existing guarantee you won't be able to
keep, for example, is that any immutable allocation can be
On Thursday, 18 February 2016 at 11:20:53 UTC, Dicebot wrote:
Consider "static if is fundamentally flawed" vs "static if is
fundamentally flawed [when applied to existing idiomatic C++
code]". Former is opinionated prejudice. Latter can quite
easily be true (even if I personally wouldn't agree
On 02/17/2016 06:47 PM, Walter Bright wrote:
If the headconst was one level up, the struct can have mutating members.
That's not headconst. It's hairconst. -- Andrei
On 02/17/2016 05:44 PM, Walter Bright wrote:
It would seem that implementing headconst as a type constructor would
let people who wanted mutable members have their way, without
introducing backdoors in const.
Doesn't seem that way to me, viz:
struct A
{
int i;
}
A __const(A) will have a
On Thursday, 18 February 2016 at 12:03:00 UTC, Walter Bright
wrote:
On 2/18/2016 2:47 AM, Timon Gehr wrote:
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable
On 2/18/2016 2:47 AM, Timon Gehr wrote:
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable reference count within a const object.
Contrary to your suggestion,
On Thursday, 18 February 2016 at 10:47:57 UTC, Timon Gehr wrote:
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable reference count within a
const object. Contrary
On 02/17/2016 01:53 PM, Andrei Alexandrescu wrote:
> On 02/16/2016 09:44 PM, Walter Bright wrote:
>> On 2/16/2016 5:35 AM, Dicebot wrote:
>>> In my opinion @mutable would be a disaster of much higher destructive
>>> impact than head const. I am very opposed to it no ma
On 02/17/2016 08:48 PM, Marc Schütz wrote:
> On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote:
>> One example of a existing guarantee you won't be able to keep, for
>> example, is that any immutable allocation can be completely put into
>> separate read-only memory.
>
> Yes, and it
On Thursday, 18 February 2016 at 06:49:34 UTC, Daniel Murphy
wrote:
It's not macroish string processing, it's embedding a subset of
C++ declarations like a DSL. The difference is that the C++
can be fully type-checked and semantically analysed, errors
will not leak into the generated source.
On 18.02.2016 10:24, Walter Bright wrote:
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
Jonathan wanted to embed a mutable reference count within a const
object. Contrary to your suggestion, headconst won't help with that.
On 2/17/2016 11:58 PM, Timon Gehr wrote:
const(headconst(T)) is the same as const(T), no?
Er, yes?
On Wednesday, 17 February 2016 at 22:01:45 UTC, Walter Bright
wrote:
On 2/17/2016 4:03 AM, Jakob Ovrum wrote:
How about disallowing immutable data with extern(C++) types?
With extern(C++)
data always mutable, `const` could safely be reused to mean
C++ const in
bindings. Any `mutable`-style
Too illustrate how headconst can help with multithreading (shared
memory) code, I have created this small snippet. In my
experience, there are lots of *effectively immutable* objects
(like Foo.bar in the code snippet). If these variables can be
declared headconst, a lot of hierarchical
On 18.02.2016 08:51, Walter Bright wrote:
On 2/17/2016 4:41 PM, Jonathan M Davis wrote:
Yes, but that really isn't going to help much code. It would be
useless for
ref-counting const objects, it wouldn't allow you to put a mutex in a
const
object, and you couldn't do anything with caching
On 2/17/2016 4:41 PM, Jonathan M Davis wrote:
Yes, but that really isn't going to help much code. It would be useless for
ref-counting const objects, it wouldn't allow you to put a mutex in a const
object, and you couldn't do anything with caching calculated properties in a
const object.
Embed
On 2/17/2016 2:38 PM, Andrei Alexandrescu wrote:
On 02/17/2016 04:07 PM, Walter Bright wrote:
On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote:
On 02/16/2016 09:53 PM, Walter Bright wrote:
Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being
Greetings
Having coded a multithreaded library in D, I sorely miss headcost
like specifier.
The library code dealt with lots of composite class object
hierarchy where many element objects of a parent are *effectively
immutable*. You build an effectively immutable object in the
constructor
On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M Davis
wrote:
On Wednesday, 17 February 2016 at 17 you're not actually
getting.
But in practice, it does prevent accidental mutation, and as
long as the programmer is behaving themselves reasonably well,
Unfortunately, the net
On 16/02/2016 8:29 PM, Ola Fosheim Grøstad wrote:
I agree with the principle, but not as a library function, because:
1. you want virtual functions to work out ok
virtual functions don't even need mangling. But even if they did it
would work just fine anyway.
2. making D more reliant
about the lack of head-const. And what's usually the
case is that folks want logical const, and I don't see how that's
possible without either having something similar to C++'s mutable
or make it well-defined to cast away const and mutate.
Having something similar to C++'s mutable would
On 2/17/2016 3:12 PM, Jonathan M Davis wrote:
On Wednesday, 17 February 2016 at 22:44:27 UTC, Walter Bright wrote:
It would seem that implementing headconst as a type constructor would let
people who wanted mutable members have their way, without introducing
backdoors in const.
I really
On Wednesday, 17 February 2016 at 22:44:27 UTC, Walter Bright
wrote:
It would seem that implementing headconst as a type constructor
would let people who wanted mutable members have their way,
without introducing backdoors in const.
I really don't see how that's the same thing at all. The
On 2/17/2016 2:31 PM, Jonathan M Davis wrote:
We _could_ have something like @mutable on member variables which made them
mutable in spite of being in a const object and which made it illegal for that
type to ever be immutable, but we'd be forced to have an additional attribute on
the type
On 02/17/2016 04:07 PM, Walter Bright wrote:
On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote:
On 02/16/2016 09:53 PM, Walter Bright wrote:
Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and full of
holes.
I thought it was the
On Wednesday, 17 February 2016 at 22:06:20 UTC, Walter Bright
wrote:
On 2/17/2016 10:54 AM, Marc Schütz wrote:
That's already covered in the DIP, see my reply to Dicebot.
Note that D supports opaque types, meaning it is not always
possible to transitively follow all types to see if they have
On 2/17/2016 10:54 AM, Marc Schütz wrote:
That's already covered in the DIP, see my reply to Dicebot.
Note that D supports opaque types, meaning it is not always possible to
transitively follow all types to see if they have mutable members.
On 2/17/2016 4:03 AM, Jakob Ovrum wrote:
How about disallowing immutable data with extern(C++) types? With extern(C++)
data always mutable, `const` could safely be reused to mean C++ const in
bindings. Any `mutable`-style code would be implemented in C++.
That doesn't help with trying to match
On 2/17/2016 3:56 AM, Andrei Alexandrescu wrote:
On 02/16/2016 09:53 PM, Walter Bright wrote:
Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and full of holes.
I thought it was the constructors and postblit that are the matter.
On Wednesday, 17 February 2016 at 19:03:25 UTC, Jonathan M Davis
wrote:
As soon as you start using pointers or containers or pointers
or anything like that, pretty quickly, you can get situations
like where the container is const, but its elements aren't.
Yes, generic containers is an issue
On Wednesday, 17 February 2016 at 18:16:54 UTC, Ola Fosheim
Grøstad wrote:
On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M
Davis wrote:
definitely sucks. But interestingly, the more I've used D, the
less happy I've been with C++'s const. It just has too many
holes. In particular,
On Wednesday, 17 February 2016 at 02:51:06 UTC, Walter Bright
wrote:
On 2/16/2016 11:29 AM, Marc Schütz wrote:
For example, it's always possible to use a global mutable
associative array to
store additional data connected with an immutable or const
object (ignoring
purity issues for the
On Wednesday, 17 February 2016 at 02:20:15 UTC, Dicebot wrote:
One example of a existing guarantee you won't be able to keep,
for example, is that any immutable allocation can be completely
put into separate read-only memory.
Yes, and it would be rejected statically (rule 2). I therefor
On Wednesday, 17 February 2016 at 17:47:02 UTC, Jonathan M Davis
wrote:
definitely sucks. But interestingly, the more I've used D, the
less happy I've been with C++'s const. It just has too many
holes. In particular, the fact that it's not transitive is
What you could consider in C++ is to
On Wednesday, 17 February 2016 at 17:25:40 UTC, rsw0x wrote:
It's weird because usually D prefers the practical solution
over the ivory tower one. Nearly every time I end up using
immutable or const for anything beyond say, a trivial function
parameter, I always end up removing it.
My C++ code
On Tuesday, 16 February 2016 at 10:31:05 UTC, Guillaume Piolat
wrote:
On Tuesday, 16 February 2016 at 01:04:44 UTC, Walter Bright
wrote:
2. supports single assignment style of programming, even if
the data is
otherwise mutable
Like 'final'? We did get rid of that...
Maybe we should
inish line. Between
not being able to have head const, needing to mutate vars in a const
object (a la refcount) and the compiler deciding functions are pure, I
often end up facing a problem where I say "okay, forget it".
And that's a real shame. We have at least one case where we're
On Wednesday, 17 February 2016 at 12:46:08 UTC, Jonathan M Davis
wrote:
but violate the type system by casting away const and mutating,
not realizing that unlike C++, it's undefined behavior in D.
Regardless of whether Walter's (and thus D's) stance on const
is the right one, it clearly
On Wednesday, 17 February 2016 at 11:56:29 UTC, Andrei
Alexandrescu wrote:
On 02/16/2016 09:53 PM, Walter Bright wrote:
Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and
full of holes.
I thought it was the constructors and
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright wrote:
rears its head again :-)
Head Const is what C++ has for const, i.e. it is not
transitive, applies to one level only. D has transitive const.
What head const will do for us:
1. make it easy to interface to C++ code that uses
On 02/16/2016 09:53 PM, Walter Bright wrote:
Most of what people find frustrating about D's transitive
const/immutable is its very nature of not being sloppy and full of holes.
I thought it was the constructors and postblit that are the matter. (It
may seem I'm on a snarky streak, but I do
On 02/16/2016 09:51 PM, Walter Bright wrote:
On 2/16/2016 11:29 AM, Marc Schütz wrote:
For example, it's always possible to use a global mutable associative
array to
store additional data connected with an immutable or const object
(ignoring
purity issues for the moment). That's safe because
On 02/16/2016 09:44 PM, Walter Bright wrote:
On 2/16/2016 5:35 AM, Dicebot wrote:
In my opinion @mutable would be a disaster of much higher destructive
impact than head const. I am very opposed to it no matter how it is
designed. Once you start considering it, you are better at simply
throwing
On 2/16/2016 9:56 PM, Ola Fosheim Grøstad wrote:
1. The compiler has access to all reachable types.
Nope. Opaque types are supported.
constness / immutability in third party libraries to
get around the limitations.
C++ added "mutable" keyword for a reason... with head const which
is much less limiting to begin with...
Furthermore, with the current mechanical guarantee of
immutability, it opens up the po
On 02/17/2016 04:44 AM, Walter Bright wrote:
> Note that head const does not introduce any watering down nor
> destruction of the const/immutable/sharing type system. The main
> downside of head const would be language complexity.
Yes, I agree - it isn't like head const is bad o
On 2/16/2016 6:20 PM, Dicebot wrote:
The problem with this DIP is that it speaks about type system semantics
and what matters first is memory model (which is currently very
under-defined as soon as you step from a "the GC" world).
Physical immutability is demanding but it also has great value
On 2/16/2016 11:29 AM, Marc Schütz wrote:
For example, it's always possible to use a global mutable associative array to
store additional data connected with an immutable or const object (ignoring
purity issues for the moment). That's safe because from the outside, there's no
observable change
On 2/16/2016 5:35 AM, Dicebot wrote:
In my opinion @mutable would be a disaster of much higher destructive
impact than head const. I am very opposed to it no matter how it is
designed. Once you start considering it, you are better at simply
throwing away existing const system and starting it all
On 02/16/2016 09:29 PM, Marc Schütz wrote:
> The last sentence in my post is crucial: "keep most of the existing
> guarantees". If we can ensure that access to @mutable data is strongly
> restricted and properly encapsulated, we don't lose anything. The type
> system would stay as it is, there
d to find a way to keep most of
>>> the existing guarantees, especially concerning shareability.
>>
>>
>> In my opinion @mutable would be a disaster of much higher destructive
>> impact than head const. I am very opposed to it no matter how it is
>> designed.
shareability.
In my opinion @mutable would be a disaster of much higher
destructive impact than head const. I am very opposed to it no
matter how it is designed. Once you start considering it, you
are better at simply throwing away existing const system and
starting it all from scratch with D3
On Tuesday, 16 February 2016 at 18:06:05 UTC, karabuta wrote:
Hahaha. Well, I think it is already happening. Like the
reincarnation of C to C++ story.
The focus on interfacing D with C++ lately has been very
disconcerting, especially considering features from TDPL are
still unfinished
On Tuesday, 16 February 2016 at 06:04:42 UTC, Jonathan M Davis
wrote:
On Monday, 15 February 2016 at 22:48:16 UTC, Walter Bright
wrote:
rears its head again :-)
Head Const is what C++ has for const, i.e. it is not
transitive, applies to one level only. D has transitive const.
What head
On Tuesday, 16 February 2016 at 16:27:54 UTC, Jonathan M Davis
wrote:
considerably. Andrei recently posted about possibly having a
reference count be in the memory next to an immutable object
but not having it in the object itself, and that might work:
I don't think I understand the semantic
1 - 100 of 158 matches
Mail list logo