On Tuesday, 16 February 2016 at 16:01:26 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 16 February 2016 at 15:33:03 UTC, Jonathan M Davis
wrote:
So, having @mutable would be far better than having it be
defined behavior to cast away const and mutate (assuming that
the underlying data is mutable
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 Tuesday, 16 February 2016 at 15:33:03 UTC, Jonathan M Davis
wrote:
const guarantees that the data will not be mutated via that
reference to the data. It guarantees nothing about other
references to that data. For that, you need immutable.
Yes, it's as weak as C++ const in most cases from
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
On Tuesday, 16 February 2016 at 15:12:00 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 16 February 2016 at 15:10:40 UTC, Timon Gehr wrote:
Legal.
Ouch... :-/
const guarantees that the data will not be mutated via that
reference to the data. It guarantees nothing about other
references to
On Tuesday, 16 February 2016 at 15:10:40 UTC, Timon Gehr wrote:
Legal.
Ouch... :-/
On 16.02.2016 14:41, Ola Fosheim Grøstad wrote:
On Tuesday, 16 February 2016 at 13:35:56 UTC, Dicebot wrote:
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. Logical const is harmful
On Tuesday, 16 February 2016 at 13:35:56 UTC, Dicebot wrote:
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. Logical const is harmful
as it doesn't give and serious guarantees but
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. Logical const is harmful as it doesn't give an
On Tuesday, 16 February 2016 at 10:17:05 UTC, Jonathan M Davis
wrote:
On Tuesday, 16 February 2016 at 10:06:12 UTC, ZombineDev wrote:
Another bonus to introducing the mutable keyword is the option
to make everything immutable by default (in a future version
of D) and allow the users to have
On Tuesday, 16 February 2016 at 11:27:56 UTC, Dicebot wrote:
On 02/16/2016 12:48 AM, 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
On Tuesday, 16 February 2016 at 10:32:45 UTC, Timon Gehr wrote:
struct S{
int[] a;
void foo()headconst{
a[0]=1; // ok
// arr.length=2 // error
}
}
void main(){
headconst(S) s([0,2,3]);
s.foo();
assert(s.a==[1,2,3]);
}
How to do this in the library?
On Tuesday, 16 February 2016 at 12:15:03 UTC, Ola Fosheim Grøstad
wrote:
Common wisdom is to compile to a high level IR first. In the
case of C++ it has worked out ok for clang. That does not mean
that there are no benefits to using a high level IR.
Let me expand on this:
1. it makes the
On Tuesday, 16 February 2016 at 12:03:48 UTC, ZombineDev wrote:
familiar with implementation details and even don't seem to
have any experience in writting large programs in D, because
Of course I don't. My goal for D is that it becomes a solid base
language which it makes sense to build
On Tuesday, 16 February 2016 at 11:02:38 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 16 February 2016 at 10:17:05 UTC, Jonathan M Davis
wrote:
version of D. We don't know what we're going to want to do at
that point, and if we're actually willing to break backwards
compatibility in a serious
On 02/16/2016 12:48 AM, 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
On 16.02.2016 11:17, Jonathan M Davis wrote:
On Tuesday, 16 February 2016 at 10:06:12 UTC, ZombineDev wrote:
Another bonus to introducing the mutable keyword is the option to make
everything immutable by default (in a future version of D) and allow
the users to have mutable objects only if they
On Tuesday, 16 February 2016 at 10:17:05 UTC, Jonathan M Davis
wrote:
version of D. We don't know what we're going to want to do at
that point, and if we're actually willing to break backwards
compatibility in a serious way, what D2 looks like doesn't
really matter much for D3. And we don't
On Tuesday, 16 February 2016 at 10:09:19 UTC, Jonathan M Davis
wrote:
On Tuesday, 16 February 2016 at 09:45:34 UTC, ZombineDev wrote:
On Tuesday, 16 February 2016 at 08:03:31 UTC, Jonathan M Davis
wrote:
...
Given that very few optimizations can be made based solely on
const (and I'm not sure
On 16.02.2016 01:14, H. S. Teoh via Digitalmars-d wrote:
Just out of curiosity, since we already have Rebindable in Phobos and
HeadConst is being proposed, what are the disadvantages / shortcomings
of a library solution that would justify adding yet another feature to
the language?
struct S{
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 resurrect it.
I'm trying to say it politely.
D2 const story is more
On Tuesday, 16 February 2016 at 10:06:12 UTC, ZombineDev wrote:
Another bonus to introducing the mutable keyword is the option
to make everything immutable by default (in a future version of
D) and allow the users to have mutable objects only if they use
the mutable keyword.
While some folks
On Tuesday, 16 February 2016 at 09:39:31 UTC, Sönke Ludwig wrote:
Am 16.02.2016 um 08:20 schrieb Ola Fosheim Grøstad:
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
On Tuesday, 16 February 2016 at 09:45:34 UTC, ZombineDev wrote:
On Tuesday, 16 February 2016 at 08:03:31 UTC, Jonathan M Davis
wrote:
...
Given that very few optimizations can be made based solely on
const (and I'm not sure that the compiler currently does any
of them) ...
I think that the
On Tuesday, 16 February 2016 at 08:03:31 UTC, Jonathan M Davis
wrote:
...
Given that very few optimizations can be made based solely on
const (and I'm not sure that the compiler currently does any of
them) ...
I think that the fact that we have shared can help a lot in the
area of
Am 16.02.2016 um 08:20 schrieb Ola Fosheim Grøstad:
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
On Tuesday, 16 February 2016 at 09:04:48 UTC, Daniel Murphy wrote:
I'm starting to think we should give up on implementing C++
support in the language and move it to the library.
eg
mixin(cppFunctionBinding("unsigned long long
NameSpace::myFunc(char * const && x, long double y)");
expands
On 16/02/2016 12:04 PM, Walter Bright wrote:
It's currently difficult to interface with C++, and always will be, but
smoothing out what we can can be a big opportunity for D.
I'm starting to think we should give up on implementing C++ support in
the language and move it to the library.
eg
On 2/15/2016 10:04 PM, Jonathan M Davis wrote:
Straight up head-const is utterly useless IMHO. That's what Java has. C++ has
something far more complicated where any individual piece (or pieces) of a
pointer type can be declared const without necessarily making the whole thing
const. So, _that_
overloaded C++
functions. Like, some C++ functions implements transitive const,
others do head const combined with mutable. So it is insufficient
to look at the C++ sigature... Which means D ought to have some
stronger way to specifing constness for C++ signatures than C++
provides.
But even
On Tuesday, 16 February 2016 at 07:20:00 UTC, Ola Fosheim Grøstad
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 07:46:11 UTC, w0rp wrote:
I think if we could avoid putting head const in the language,
we'd be better off. If you ever really, really need to mutate
something inside a const type, you can cast away const. It will
rightly look ugly, and the compiler can complain
protection from the
compiler from stopping the objects in the inside from being
mutated. The way I see it, C++ const is a weaker form of const
which doesn't complain about mutations enough.
I think if we could avoid putting head const in the language,
we'd be better off. If you ever really
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 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 Tuesday, 16 February 2016 at 01:04:44 UTC, Walter Bright wrote:
On 2/15/2016 4:15 PM, Daniel Murphy 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)
I'd much rather improve pragma(mangle)
On Mon, 15 Feb 2016 16:57:44 -0800, H. S. Teoh via Digitalmars-d wrote:
> What about besides C++ integration? 'cos I remember some people were
> complaining that a library solution is bad, but I've forgotten what the
> reasons were.
The first problem mentioned was C++ integration, and the
On 2/15/2016 4:15 PM, Daniel Murphy 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)
I'd much rather improve pragma(mangle) than add more C++ features to D.
It's currently difficult to
On Tue, Feb 16, 2016 at 12:21:38AM +, Chris Wright via Digitalmars-d wrote:
> On Mon, 15 Feb 2016 16:14:23 -0800, H. S. Teoh via Digitalmars-d wrote:
> > Just out of curiosity, since we already have Rebindable in Phobos
> > and HeadConst is being proposed, what are the disadvantages /
> >
On Mon, 15 Feb 2016 16:14:23 -0800, H. S. Teoh via Digitalmars-d wrote:
> Just out of curiosity, since we already have Rebindable in Phobos and
> HeadConst is being proposed, what are the disadvantages / shortcomings
> of a library solution that would justify adding yet another feature to
> the
On 16/02/2016 9:48 AM, 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 const, as currently
On Mon, Feb 15, 2016 at 11:45:26PM +, ZombineDev via Digitalmars-d wrote:
[...]
> >I used the term "tail const" as a mutable pointer/reference to
> >const/immutable object, where transitivity starts from the object
> >(not from the pointer, which is what currently happens if you type
> >`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
solutions in
this area:
HeadConst [1] - PR pending, and
Rebindable (tail const) [2] - already part of Phobos.
Maybe if the language could express head const, it also makes
sense to have tail
const.
[1]:
https://github.com/D-Programming-Language/phobos/pull/3862
[2]:
http://dlang.org/phobos
On 2/15/2016 3:39 PM, ZombineDev wrote:
I used the term "tail const" as a mutable pointer/reference to const/immutable
object, where transitivity starts from the object (not from the pointer, which
is what currently happens if you type `const Object o`).
Makes sense.
, and
Rebindable (tail const) [2] - already part of Phobos.
Maybe if the language could express head const, it also makes
sense to have tail
const.
[1]: https://github.com/D-Programming-Language/phobos/pull/3862
[2]:
http://dlang.org/phobos-prerelease/std_typecons.html#.Rebindable
Transitive const
On Monday, 15 February 2016 at 23:28:28 UTC, Walter Bright wrote:
Transitive const is tail const.
const(char)[] foo is tail const
const(Object) ref is the analog the language is missing so phobos
tries to catch up
if the language could express head const, it also makes sense to have tail
const.
[1]: https://github.com/D-Programming-Language/phobos/pull/3862
[2]: http://dlang.org/phobos-prerelease/std_typecons.html#.Rebindable
Transitive const is tail 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
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 const, as currently it is not
very practical to do so, you have
https://issues.dlang.org/show_bug.cgi?id=13796
Issue ID: 13796
Summary: A simple array head const struct for Phobos
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
In D code it's a good idea to set as const/immutable (where
possible) all variables that don't need to change, for both
safety and compiler-enforced code documentation.
In my D functions sometimes I create dynamic arrays that later
don't have to change length nor to be reassigned, but I have to
On Friday, 28 November 2014 at 10:55:27 UTC, bearophile wrote:
In D code it's a good idea to set as const/immutable (where
possible) all variables that don't need to change, for both
safety and compiler-enforced code documentation.
In my D functions sometimes I create dynamic arrays that later
Dominikus Dittes Scherkl:
Why you don't use static arrays for such a purpose?
I thought this is exactly what they are made for, aren't they?
Currently you can't create a static array with a length known
only at run-time. And passing around a fixed-size arrays has some
costs.
Bye,
On Friday, 28 November 2014 at 10:55:27 UTC, bearophile wrote:
In D code it's a good idea to set as const/immutable (where
possible) all variables that don't need to change, for both
safety and compiler-enforced code documentation.
In my D functions sometimes I create dynamic arrays that later
I'm contemplating using D for an embedded project where system
configuration registers have fixed memory locations.
One way of doing it would be to have a constant pointer to a structure
with manually aligned members that match the register map, and access
them like that. This becomes
Hi,
I'm contemplating using D for an embedded project where system
configuration registers have fixed memory locations.
One way of doing it would be to have a constant pointer to a structure
with manually aligned members that match the register map, and access
them like that. This becomes
Hi,
I'm contemplating using D for an embedded project where system
configuration registers have fixed memory locations.
One way of doing it would be to have a constant pointer to a structure
with manually aligned members that match the register map, and access
them like that. This becomes
101 - 158 of 158 matches
Mail list logo
