On Sat, 06 Aug 2016 07:56:29 +0200, ag0aep6g wrote:
> On 08/06/2016 03:38 AM, Chris Wright wrote:
>> Some reflection stuff is a bit inconvenient:
>>
>> class A {
>> int foo() { return 1; }
>> }
>>
>> void main() {
>> auto a = new immutable(A);
>> // This passes:
>> static
On 06.08.2016 07:56, ag0aep6g wrote:
Add parentheses to the typeof one and it fails as expected:
static assert(is(typeof(a.foo(; /* fails */
Can also do the function literal thing you did in the __traits one:
static assert(is(typeof(() { a.foo; }))); /* fails */
You can, but
On 08/06/2016 03:57 AM, Mark J Twain wrote:
On Friday, 5 August 2016 at 21:12:06 UTC, ag0aep6g wrote:
[...]
struct MutableSomething
{
int value;
void mutate(int newValue) { value = newValue; }
}
struct ImmutableSomething
{
int value;
/* no mutate method here */
}
void
On 08/06/2016 03:38 AM, Chris Wright wrote:
Some reflection stuff is a bit inconvenient:
class A {
int foo() { return 1; }
}
void main() {
auto a = new immutable(A);
// This passes:
static assert(is(typeof(a.foo)));
// This doesn't:
static assert(__traits(compiles, () { a.foo; }));
On Sat, 06 Aug 2016 01:57:50 +, Mark "J" Twain wrote:
> wow, that seems like a huge design issues.
In practice, it's not a problem. In a language supporting low-level
operations, you do sometimes need a reinterpret_cast. And since there's
no other useful cast you can do with a D struct...
On Friday, 5 August 2016 at 21:12:06 UTC, ag0aep6g wrote:
On 08/05/2016 09:39 PM, Mark J Twain wrote:
In the case of ImmutableQueue, There is no Enqueue!
See, there is a difference between "not callable" and "does
not exists".
Ok, but what cool stuff is enabled by "does not exist" that
On Fri, 05 Aug 2016 23:12:06 +0200, ag0aep6g wrote:
> On 08/05/2016 09:39 PM, Mark J Twain wrote:
>> In the case of ImmutableQueue, There is no Enqueue!
>>
>> See, there is a difference between "not callable" and "does not
>> exists".
>
> Ok, but what cool stuff is enabled by "does not exist"
On 08/05/2016 09:39 PM, Mark J Twain wrote:
In the case of ImmutableQueue, There is no Enqueue!
See, there is a difference between "not callable" and "does not exists".
Ok, but what cool stuff is enabled by "does not exist" that doesn't work
(as nicely) with "not callable"? As far as I can
On Thursday, 4 August 2016 at 18:58:18 UTC, ag0aep6g wrote:
On 08/04/2016 08:22 PM, Mark J Twain wrote:
The problem is that you have fixated on the *array* and not
the general
principle. The Array was an example.
I'm having trouble understanding what you're getting at, so I'm
trying to get
On Thursday, 4 August 2016 at 18:22:52 UTC, Mark "J" Twain wrote:
Building immutability in to the type system itself allows the
programmer to make immutable smarter and control exactly what
it does.
once again it is in the type system:
°°
On Thursday, 4 August 2016 at 18:22:52 UTC, Mark "J" Twain wrote:
Marking a widget immutable is not the same as having an
ImmutableWidget. Can you see the difference?
Yes, you're thinking here of logical vs physical immutability.
I assure you there is. The immutable keyword only prevents data
On 08/04/2016 08:22 PM, Mark J Twain wrote:
The problem is that you have fixated on the *array* and not the general
principle. The Array was an example.
I'm having trouble understanding what you're getting at, so I'm trying
to get it from the example you gave. If there's merit in your idea,
On Thursday, 4 August 2016 at 13:08:11 UTC, ag0aep6g wrote:
On 08/03/2016 09:33 PM, Mark J Twain wrote:
The built in array is mutable and exposes the same interface
for the
immutable copy. The only difference is that the immutable copy
is marked
immutable.
I don't understand. An immutable
On 08/03/2016 09:33 PM, Mark J Twain wrote:
The built in array is mutable and exposes the same interface for the
immutable copy. The only difference is that the immutable copy is marked
immutable.
I don't understand. An immutable array does not let you overwrite
elements. A mutable array
On Wednesday, 3 August 2016 at 08:09:41 UTC, qznc wrote:
On Tuesday, 2 August 2016 at 21:48:58 UTC, Mark Twain wrote:
global ImmutableArray!int Data;
MutableArray!int DataCopy = Data.Copy; // Creates a mutable
copy of Data.
... Do work with DataCopy ...
Data.Replace(DataCopy); // Makes a
On Wednesday, 3 August 2016 at 05:44:42 UTC, ag0aep6g wrote:
On 08/02/2016 11:48 PM, Mark Twain wrote:
global ImmutableArray!int Data;
MutableArray!int DataCopy = Data.Copy; // Creates a mutable
copy of Data.
... Do work with DataCopy ...
Data.Replace(DataCopy); // Makes a copy of DataCopy.
On Tuesday, 2 August 2016 at 21:48:58 UTC, Mark Twain wrote:
global ImmutableArray!int Data;
MutableArray!int DataCopy = Data.Copy; // Creates a mutable
copy of Data.
... Do work with DataCopy ...
Data.Replace(DataCopy); // Makes a copy of DataCopy.
I see the problem that you cannot
On 08/02/2016 11:48 PM, Mark Twain wrote:
global ImmutableArray!int Data;
MutableArray!int DataCopy = Data.Copy; // Creates a mutable copy of Data.
... Do work with DataCopy ...
Data.Replace(DataCopy); // Makes a copy of DataCopy.
What benefit do ImmutableArray and MutableArray have over
On Tuesday, 2 August 2016 at 21:48:58 UTC, Mark Twain wrote:
[...]
Another useful feature I forgot to mention is that we can cast
between Immutable and Muttable types.
class ImmutableTest
{
private MutableArray!int data;
public ImmutableArray!int Data;
this()
{
//
One of the biggest problems with memory is that it's inherently
unsafe. We know the solution to that is immutability. Immutable
memory is inherently safe. The problem is that Immutable memory
is useless because it cannot be changed. To make it useful and
safe we have to cheat by creating
20 matches
Mail list logo
