On 05/09/14 01:05, Sönke Ludwig via Digitalmars-d wrote:
Am 09.05.2014 00:02, schrieb Timon Gehr:
On 05/08/2014 06:30 PM, Sönke Ludwig wrote:
Am 08.05.2014 18:10, schrieb Timon Gehr:
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you
void main()
{
DemoStruct m;
test(m);
acceptor(immutable) i;
I mean:
acceptor(immutable) DemoStruct i
test(i);
}
On Thursday, 8 May 2014 at 21:08:36 UTC, bearophile wrote:
I think T1 and T2 should be equivalent for built-in tuples.
There are no built-in tuples in D.
On Thursday, 8 May 2014 at 11:05:20 UTC, monarch_dodra wrote:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for
range/slice types, but for any user defined reference type
(e.g. RefCounted!T or Isolated!T).
Not necessarily: As
Andrei Alexandrescu:
making user-defined types as powerful as built-in types is a
Good Thing(tm).
An example of something useful that I think is not currently easy
to do with user-defined types (but I think this could be done by
future built-in tuples):
Tuple!(ref int, bool) foo(ref int
On Wed, 07 May 2014 20:58:21 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
So there's this recent discussion about making T[] be refcounted if
and only if T has a destructor.
That's an interesting idea. More generally, there's the notion that
making
On Thu, 08 May 2014 06:48:57 +
bearophile via Digitalmars-d digitalmars-d@puremagic.com wrote:
Currently only the slices decay in mutables, while an immutable
int doesn't become mutable:
That's because what's happening is that the slice operator for arrays is
defined to return a tail-const
Just a general note: This is not only interesting for range/slice types,
but for any user defined reference type (e.g. RefCounted!T or Isolated!T).
On 05/08/2014 05:58 AM, Andrei Alexandrescu wrote:
...
import std.stdio;
void fun(T)(T x)
{
writeln(typeof(x).stringof);
}
void main()
{
immutable(int[]) a = [ 1, 2 ];
writeln(typeof(a).stringof);
fun(a);
}
This program outputs:
immutable(int[])
immutable(int)[]
which means
On 2014-05-08 03:58:21 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
So there's this recent discussion about making T[] be refcounted if and
only if T has a destructor.
That's an interesting idea. More generally, there's the notion that
making user-defined types as powerful
On 05/08/2014 08:55 AM, Jonathan M Davis via Digitalmars-d wrote:
As far as I can see, opByValue does the same thing as opSlice, except
that it's used specifically when passing to functions, whereas this code
immutable int [] a = [1, 2, 3];
immutable(int)[] b = a[];
or even
immutable int [] a
On 05/08/2014 12:14 PM, Michel Fortin wrote:
Will this solve the problem that const(MyRange!(const T)) is a different
type from const(MyRange!(T))?
No, but as stated it aggravates this problem.
I doubt it. But they should be the same
type if we want to follow the semantics of the language's
On Thu, 08 May 2014 12:38:44 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 05/08/2014 08:55 AM, Jonathan M Davis via Digitalmars-d wrote:
As far as I can see, opByValue does the same thing as opSlice,
except that it's used specifically when passing to functions,
On 05/08/2014 09:01 AM, Jonathan M Davis via Digitalmars-d wrote:
It really has nothing to do with passing an argument to a function
beyond the fact that that triggers an implicit call to the slice operator.
module check_claim;
import std.stdio;
auto foo(immutable(int)[] a){writeln(Indeed,
On Thursday, 8 May 2014 at 03:58:16 UTC, Andrei Alexandrescu
wrote:
This change would allow library designers to provide good
solutions to making immutable and const ranges work properly -
the way T[] works.
There are of course a bunch of details to think about and
figure out, and this is a
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for
range/slice types, but for any user defined reference type
(e.g. RefCounted!T or Isolated!T).
Not necessarily: As soon as indirections come into play, you are
basically screwed,
Am 08.05.2014 13:05, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for range/slice
types, but for any user defined reference type (e.g. RefCounted!T or
Isolated!T).
Not necessarily: As soon as indirections
On Thursday, 8 May 2014 at 12:48:17 UTC, Sönke Ludwig wrote:
Am 08.05.2014 13:05, schrieb monarch_dodra:
Not necessarily: As soon as indirections come into play, you
are
basically screwed, since const is turtles all the way down.
So for example, the conversion from const RefCounted!T to
On 05/08/2014 01:05 PM, monarch_dodra wrote:
...
In fact, I'm wondering if this might not be a more interesting direction
to explore.
http://forum.dlang.org/thread/ljrm0d$28vf$1...@digitalmars.com?page=3#post-ljrt6t:242fpc:241:40digitalmars.com
On Thu, 08 May 2014 14:48:18 +0200
Sönke Ludwig via Digitalmars-d digitalmars-d@puremagic.com wrote:
Am 08.05.2014 13:05, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for range/slice
types, but for any
On Thu, May 08, 2014 at 11:05:19AM +, monarch_dodra via Digitalmars-d wrote:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note: This is not only interesting for range/slice
types, but for any user defined reference type (e.g. RefCounted!T or
Isolated!T).
Am 08.05.2014 15:57, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 12:48:17 UTC, Sönke Ludwig wrote:
Am 08.05.2014 13:05, schrieb monarch_dodra:
Not necessarily: As soon as indirections come into play, you are
basically screwed, since const is turtles all the way down.
So for example, the
Am 08.05.2014 16:22, schrieb Jonathan M Davis via Digitalmars-d:
On Thu, 08 May 2014 14:48:18 +0200
Sönke Ludwig via Digitalmars-d digitalmars-d@puremagic.com wrote:
Am 08.05.2014 13:05, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 07:09:24 UTC, Sönke Ludwig wrote:
Just a general note:
On Thursday, 8 May 2014 at 15:39:24 UTC, Sönke Ludwig wrote:
Unless I'm completely mistaken, it's safe to cast away const
when it is known that the original reference was constructed as
mutable.
Depends. If the original type referencing the (originally
mutable) allocated data happens to be
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you can cast
away all the const you want, but at that point, it kind of makes the
whole const thing moot.
This is not guaranteed to work. I guess the only related thing that is
safe to do
On Thursday, 8 May 2014 at 16:30:13 UTC, Sönke Ludwig wrote:
For what practical reason would that be the case? I know that
the spec states undefined behavior, but AFAICS, there is
neither an existing, nor a theoretical reason, why this should
fail:
Compiler optimizations based on
Am 08.05.2014 18:10, schrieb Timon Gehr:
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you can cast
away all the const you want, but at that point, it kind of makes the
whole const thing moot.
This is not guaranteed to work. I guess
Am 08.05.2014 18:33, schrieb David Nadlinger:
On Thursday, 8 May 2014 at 16:30:13 UTC, Sönke Ludwig wrote:
For what practical reason would that be the case? I know that the spec
states undefined behavior, but AFAICS, there is neither an existing,
nor a theoretical reason, why this should fail:
Am 08.05.2014 18:02, schrieb monarch_dodra:
On Thursday, 8 May 2014 at 15:39:24 UTC, Sönke Ludwig wrote:
Unless I'm completely mistaken, it's safe to cast away const when it
is known that the original reference was constructed as mutable.
Depends. If the original type referencing the
Andrei Alexandrescu:
That's an interesting idea. More generally, there's the notion
that making user-defined types as powerful as built-in types is
a Good Thing(tm).
Regarding the management of const for library-defined types,
sometimes I'd like the type T1 to be seen as equal to the type
On 05/08/2014 06:30 PM, Sönke Ludwig wrote:
Am 08.05.2014 18:10, schrieb Timon Gehr:
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you can cast
away all the const you want, but at that point, it kind of makes the
whole const thing
Am 09.05.2014 00:02, schrieb Timon Gehr:
On 05/08/2014 06:30 PM, Sönke Ludwig wrote:
Am 08.05.2014 18:10, schrieb Timon Gehr:
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you can cast
away all the const you want, but at that point,
On Thu, 08 May 2014 16:33:06 +
David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Thursday, 8 May 2014 at 16:30:13 UTC, Sönke Ludwig wrote:
For what practical reason would that be the case? I know that
the spec states undefined behavior, but AFAICS, there is
On Thu, 08 May 2014 17:18:03 +0200
Sönke Ludwig via Digitalmars-d digitalmars-d@puremagic.com wrote:
Right, which is my point: const(RefCount!T) *is* dysfunctional,
which is why you'd want to skip it out entirely in the first
place.This holds true for types implemented with RefCount, such
On Thu, 08 May 2014 17:39:25 +0200
Sönke Ludwig via Digitalmars-d digitalmars-d@puremagic.com wrote:
Am 08.05.2014 16:22, schrieb Jonathan M Davis via Digitalmars-d:
On Thu, 08 May 2014 14:48:18 +0200
Sönke Ludwig via Digitalmars-d digitalmars-d@puremagic.com wrote:
Am 08.05.2014 13:05,
On Thu, 08 May 2014 18:10:28 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 05/08/2014 06:02 PM, monarch_dodra wrote:
If you have const data referencing mutable data, then yes, you can
cast away all the const you want, but at that point, it kind of
makes the
So there's this recent discussion about making T[] be refcounted if and
only if T has a destructor.
That's an interesting idea. More generally, there's the notion that
making user-defined types as powerful as built-in types is a Good Thing(tm).
Which brings us to something that T[] has that
This looks like interesting.
On 8.5.2014. 5:58, Andrei Alexandrescu wrote:
This magic of T[] is something that custom ranges can't avail themselves
of. In order to bring about parity, we'd need to introduce opByValue
which (if present) would be automatically called whenever the object is
passed by value into a function.
39 matches
Mail list logo
