On Thursday, 5 December 2019 at 12:00:23 UTC, Ola Fosheim Grøstad
wrote:
So basically, templated functions get flow-typing.
But it is not reliable :-(
struct node {int value; node* next;}
node n0 = {1,null};
node mk_node1()(node* n){
node tmp = {2019, n};
return tmp;
}
node mk_node
So basically, templated functions get flow-typing. I guess that
is a good reason to use templated functions more...
What is the downside? E.g.:
struct node {int value; node* next;}
node mk_node2()(){
node tmp = {2019, null};
return tmp;
}
node mk_node(){
node tmp = {2019, null};
On Thursday, 5 December 2019 at 10:41:24 UTC, Ola Fosheim Grøstad
wrote:
immutable x1 = mk!node1(); //succeeds?
immutable y1 = mk_node1(); //fails
Nevermind, seems like templated functions get stronger coercion,
like:
immutable y1 = cast(immutable)mk_node1();
(Also no need to exp
I also find the following behaviour a bit unclear:
struct node0 {int value; node0* next;}
struct node1 {int value; const(node1)* next;}
struct node2 {int value; immutable(node0)* next;}
T mk(T)(){
T tmp = {2019, null};
return tmp;
}
node1 mk_node1(){
node1 tmp = {2019, null};
re
On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven
Schveighoffer wrote:
void foo(alias f)()
{
alias ConstType = const(typeof(f()));
pragma(msg, ConstType);
}
I expressed myself poorly, what I am interested in is this:
struct node1 {int value; const(node1)* next;}
struct node2 {int val
I haven't used const much in the past because I got burned on
transitive const, so I managed to confuse myself. I am not
really interested in const/immutabel references here, only
values. Seems like there is no reason to ever use const values,
except when the value may contain a pointer to som
I haven't used const much in the past because I got burned on
transitive const, so I managed to confuse myself. I am not
really interested in const/immutabel references here, but values.
Seems like there is no reason to ever use const values, except
when they contain a pointer to something non
On Thursday, 5 December 2019 at 00:05:26 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven
Schveighoffer wrote:
void main()
{
foo!a(); // const(int)
foo!b(); // immutable(int)
foo!c(); // const(int)
}
Ok, so one has to use a wrapper and then "cat
On Wednesday, 4 December 2019 at 23:27:49 UTC, Steven
Schveighoffer wrote:
void main()
{
foo!a(); // const(int)
foo!b(); // immutable(int)
foo!c(); // const(int)
}
Ok, so one has to use a wrapper and then "catch" the result with
auto?
auto x = foo!f();
On 12/4/19 5:57 PM, Ola Fosheim Grøstad wrote:
On Wednesday, 4 December 2019 at 22:51:01 UTC, Ola Fosheim Grøstad wrote:
Is there a way to specify in generic code that you want the best fit
of a const/immutable reference depending on the return type (but not a
mutable one)?
I mean, if f() ret
On Wednesday, 4 December 2019 at 22:51:01 UTC, Ola Fosheim
Grøstad wrote:
Is there a way to specify in generic code that you want the
best fit of a const/immutable reference depending on the return
type (but not a mutable one)?
I mean, if f() return mutable or const then it should be const,
b
On Wednesday, 4 December 2019 at 22:43:35 UTC, Bastiaan Veelo
wrote:
There is a difference I guess if g() returns a reference type
and is an inout function. immutable y will only work if the
reference returned is immutable.
But not for values?
Const is a promise to the rest of the code that y
On Wednesday, 4 December 2019 at 14:44:43 UTC, Ola Fosheim
Grøstad wrote:
When is there a noticable difference when using const values
instead of immutable values in a function body? And when should
immutable be used instead of const?
f(){
const x = g();
immutable y = g();
... do stuff w
On Wednesday, 4 December 2019 at 22:29:13 UTC, kerdemdemir wrote:
Unfortunately I am not yet good with D to answer your question .
But Ali Çehreli made some comparesions with C++.
https://dconf.org/2013/talks/cehreli.pdf
And I think you will find the answers of your questions in it
also.
Thank
On Wednesday, 4 December 2019 at 14:44:43 UTC, Ola Fosheim
Grøstad wrote:
When is there a noticable difference when using const values
instead of immutable values in a function body? And when should
immutable be used instead of const?
f(){
const x = g();
immutable y = g();
... do stuff w
Also, in file scope, would C++:
constexpr auto constant = 3;
be the same as:
immutable constant = 3;
?
When is there a noticable difference when using const values
instead of immutable values in a function body? And when should
immutable be used instead of const?
f(){
const x = g();
immutable y = g();
... do stuff with x and y …
}
I'm comparing D to C++ and I get the following mapping:
D
On Wednesday, 3 February 2016 at 06:11:07 UTC, H. S. Teoh wrote:
I still can't come up with a compelling use case that would
justify using a const/immutable class member, that couldn't be
done by some other means, though. Especially since we're
talking about classes, we already have all the tra
ll folks not to do it because of all of the problems
> > > it causes.
> >
> > That's been my guideline: "const and immutable members should be
> > avoided." Now I'm tempted to add this: "only in structs."
>
> IIRC, I've pretty
On Tuesday, February 02, 2016 19:32:39 Ali Çehreli via Digitalmars-d-learn
wrote:
> On 02/02/2016 07:05 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> > I usually tell folks not to do it because of
> > all of the problems it causes.
>
> That's been my guide
that problem,
because
> you don't normally ever try to overwrite the state of the whole class
> object.
Exactly my point.
> I usually tell folks not to do it because of
> all of the problems it causes.
That's been my guideline: "const and immutable members should be
avoided." Now I'm tempted to add this: "only in structs."
Ali
On Tuesday, February 02, 2016 18:14:50 H. S. Teoh via Digitalmars-d-learn wrote:
> On Tue, Feb 02, 2016 at 05:49:00PM -0800, Jonathan M Davis via
> Digitalmars-d-learn wrote:
> > On Tuesday, February 02, 2016 14:48:03 Ali Çehreli via Digitalmars-d-learn
> > wrote:
> &g
On Tue, Feb 02, 2016 at 05:49:00PM -0800, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Tuesday, February 02, 2016 14:48:03 Ali Çehreli via Digitalmars-d-learn
> wrote:
> > const and immutable members make structs non-assignable:
[...]
> > That's why I've b
On Tuesday, February 02, 2016 14:48:03 Ali Çehreli via Digitalmars-d-learn
wrote:
> const and immutable members make structs non-assignable:
>
> struct S {
> const int c;// Makes S non-assignable
> immutable int i;// Makes S non-assignable
> }
>
> voi
On 02/02/2016 03:02 PM, anonymous wrote:
> I'm not sure what you mean by "default assignment".
I think I meant member-wise assignment. :)
> I'd say it works
> more simply with classes, because they're reference types. It's the same
> as using pointers to structs:
>
> auto a = new S();
> auto b
On 02.02.2016 23:48, Ali Çehreli wrote:
struct S {
const int c;// Makes S non-assignable
immutable int i;// Makes S non-assignable
}
void main() {
auto a = S();
auto b = S();
a = b; // Compilation ERROR
}
(That is the same issue in C++.)
That's
const and immutable members make structs non-assignable:
struct S {
const int c;// Makes S non-assignable
immutable int i;// Makes S non-assignable
}
void main() {
auto a = S();
auto b = S();
a = b; // Compilation ERROR
}
(That is the same issue in
On Monday, September 23, 2013 13:49:59 Daniel Davidson wrote:
> > But if your concern is client code messing with your member
> > variable, then
> > don't give them access to it in the first place.
>
> Not quite as much messing with the member as messing with what it
> points to. In the setup - ri
On Monday, 23 September 2013 at 03:51:41 UTC, Jonathan M Davis
wrote:
Doesn't using immutable there present the same problem as with
the slice? S is no longer assignable. But who would recommend
not
using immutable in this case if you want aarr to be stable. If
you do not use immutable then who
n any of the elements in those arrays. Best case, you can
mutate their members that aren't const or immutable, but all of their const
and immutable members are stuck referring to the value in S.init.
Anywhere that involves S.init stops working properly, because you can't change
any S
On Sunday, 22 September 2013 at 20:17:03 UTC, Jonathan M Davis
wrote:
If you have
struct S
{
immutable int[] arr;
}
then arr can never be assigned to, so a variable of type S can
never be
assigned to. But if you have
Yes - it (arr) can never be assigned to. That is the idea. It has
alr
On Sunday, 22 September 2013 at 16:15:09 UTC, Daniel Davidson
wrote:
[...]
3) Also, is storing immutable(STUFF) in a struct in the
general
case (as opposed to just this one) useful or silly?
[...]
I don't really understand the _tail-const_, _tail-immutable_
argument. Why is _tail-const_ f
does not restrict the class, which means that if you want to make it
so that the member variable can't be reassigned, making it fully const or
fully immutable is fine.
> I think there are only a handful of places you consider using
> const/immutable:
>
> - Global variabl
In this thread
(http://forum.dlang.org/thread/uvhwkgljavskqfueq...@forum.dlang.org)
I asked this:
3) Also, is storing immutable(STUFF) in a struct in the general
case (as opposed to just this one) useful or silly?
Johnathan M Davis replied:
As soon as you have a const or immutable member i
On Tue, 06 Jul 2010 16:08:21 -0400, Tim Verweij
wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
I'm not positive, but I think the second const applies to the second
function, I think you meant:
const Bar& GetBar() const { return mBar; }
Uh, yes, of course. Pff, I fe
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> I'm not positive, but I think the second const applies to the second
> function, I think you meant:
> const Bar& GetBar() const { return mBar; }
Uh, yes, of course. Pff, I feel bad for making such an embarrasing mistake.
> And ye
On Tue, 06 Jul 2010 12:10:04 -0400, Tim Verweij
wrote:
Not sure if I'm double posting now. Sorry if I am, but I didn't see my
own post
appear this time.
Anyway, thanks for your replies, that was very helpful. I had one more
question
about inout. If I understand correctly it cannot be use
Not sure if I'm double posting now. Sorry if I am, but I didn't see my own post
appear this time.
Anyway, thanks for your replies, that was very helpful. I had one more question
about inout. If I understand correctly it cannot be used to get rid of the
double
GetBar function in the following C++
Thanks for all replies, that was very helpful. I have one more question about
inout. If I understand correctly, it is always coupled to the use of a parameter
and cannot be used to get rid of the double GetBar in the following C++ example:
class Foo
{
public:
const Bar& GetBar() { return bar; }
On Tue, 06 Jul 2010 10:56:11 -0400, Tim Verweij
wrote:
Hey all,
I'm having some trouble understanding the whole const and immutable of
D2,
especially since it seems documentation is not consistent (Or I'm
missing some
things). I write quite a lot of C++ code btw, so I'
Hello Tim,
I think I understand the difference between const and immuable when
considering references and pointers, but how exactly is const
different from immutable in:
[...]
const(int) somefunc(); versus immutable(int) somefunc();
BTW both of those are pointless. The following works:
imp
Tim Verweij wrote:
http://www.digitalmars.com/d/2.0/const3.html includes D examples like:
void foo(const int* x, int* y)
Is the information on the first page not updated for D2?
That seems correct.
Is the following correct? (this confuses me)
immutable int somefunc();
means the same
Hey all,
I'm having some trouble understanding the whole const and immutable of D2,
especially since it seems documentation is not consistent (Or I'm missing some
things). I write quite a lot of C++ code btw, so I'm familiar with that.
---
http://www.digitalmars.com/d/2.0/htomodu
43 matches
Mail list logo
