Did you ever get around to making a pull request for this? It'd
be nice to have this in Phobos, so I can make one for you (all
attribution to you, of course) if you don't have time to push it
through.
On Tue, Oct 21, 2014 at 11:37:09PM +, Meta via Digitalmars-d wrote:
Did you ever get around to making a pull request for this? It'd be
nice to have this in Phobos, so I can make one for you (all
attribution to you, of course) if you don't have time to push it
through.
No, I've been too
On 2014-06-24 22:52, Ary Borenszweig wrote:
And in Ruby it's just ||=. How more intuitive can it get?
a = nil
a ||= 1
The or that you are discussing here is just an || in Ruby:
b = nil || 1
Yeah, but that behaves a bit different in D.
--
/Jacob Carlborg
On Sunday, 22 June 2014 at 08:15:45 UTC, Andrei Alexandrescu
wrote:
On 6/21/14, 3:38 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 6/19/14, 1:29 PM, Etienne wrote:
On 2014-06-24 18:52, Yota wrote:
On Sunday, 22 June 2014 at 08:15:45 UTC, Andrei Alexandrescu wrote:
On 6/21/14, 3:38 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 6/19/14, 1:29 PM, Etienne wrote:
On Tue, Jun 24, 2014 at 09:43:21PM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-06-24 18:52, Yota wrote:
On Sunday, 22 June 2014 at 08:15:45 UTC, Andrei Alexandrescu wrote:
On 6/21/14, 3:38 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei
On 6/24/14, 4:43 PM, Jacob Carlborg wrote:
On 2014-06-24 18:52, Yota wrote:
On Sunday, 22 June 2014 at 08:15:45 UTC, Andrei Alexandrescu wrote:
On 6/21/14, 3:38 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On
On Tuesday, 24 June 2014 at 19:56:14 UTC, H. S. Teoh via
Digitalmars-d wrote:
So D code is going to start looking like this now?!
if (myobj.elvis.subobj.memb.isAlive.or(false)) {
...
}
What about ifExists?
if (myObj.ifExists.subobj.member.isAlive.or(false))
{
On 6/21/14, 4:32 PM, deadalnix wrote:
On Saturday, 21 June 2014 at 22:40:32 UTC, H. S. Teoh via Digitalmars-d
wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 6/19/14, 1:29 PM, Etienne wrote:
On 6/21/14, 3:38 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 6/19/14, 1:29 PM, Etienne wrote:
writeln(currAssignment.safeDeref.typeInfo.ident.or(meh));
or is really nice and terse. I think we should add
On Sun, Jun 22, 2014 at 01:15:46AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 6/21/14, 3:38 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 6/19/14, 1:29 PM, Etienne wrote:
On 6/22/14, 7:26 AM, H. S. Teoh via Digitalmars-d wrote:
On Sun, Jun 22, 2014 at 01:15:46AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 6/21/14, 3:38 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On
On 6/19/14, 1:29 PM, Etienne wrote:
writeln(currAssignment.safeDeref.typeInfo.ident.or(meh));
or is really nice and terse. I think we should add that to std.
safeDeref isn't the best choice of name.
Andrei
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 6/19/14, 1:29 PM, Etienne wrote:
writeln(currAssignment.safeDeref.typeInfo.ident.or(meh));
or is really nice and terse. I think we should add that to std.
safeDeref isn't the best choice of name.
[...]
On Saturday, 21 June 2014 at 22:40:32 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, Jun 21, 2014 at 03:26:45PM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 6/19/14, 1:29 PM, Etienne wrote:
writeln(currAssignment.safeDeref.typeInfo.ident.or(meh));
or is really nice and terse. I
On 2014-06-19 6:23 PM, H. S. Teoh via Digitalmars-d wrote:
Unfortunately, it appears that opDispatch has become too complex to be
inlined, so now gdc is unable to simplify it to a series of nested if's.
:-(
T
Meh, I don't mind specifying that condition manually after all... having
a
On 2014-06-19 6:30 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 19, 2014 at 03:23:33PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
Unfortunately, it appears that opDispatch has become too complex to be
inlined, so now gdc is unable to simplify it to a series of nested
if's. :-(
On Wednesday, 18 June 2014 at 15:57:40 UTC, Etienne wrote:
On 2014-06-18 11:55 AM, bearophile wrote:
Etienne:
writeln(obj.member?.nested?.val);
What about an approach like Scala instead?
Bye,
bearophile
You mean like this?
On Fri, Jun 20, 2014 at 08:57:46AM -0400, Etienne via Digitalmars-d wrote:
On 2014-06-19 6:23 PM, H. S. Teoh via Digitalmars-d wrote:
Unfortunately, it appears that opDispatch has become too complex to
be inlined, so now gdc is unable to simplify it to a series of nested
if's.
:-(
T
On 2014-06-20 10:29 AM, H. S. Teoh via Digitalmars-d wrote:
True. Actually, I did my disassembly test again, and now I can't seem to
coax gdc to optimize out the .exists flag, esp. when .or is involved.
Perhaps that was a little too ambitious; maybe it's better to stick with
the original simple
On 2014-06-19 16:37, Craig Dillabaugh wrote:
Is this any better than?
if(!a) a = b;
I would say it's about the same as a ?? b is better than a ? a : b.
It's get better since you can use it directly in a return statement:
void a ()
{
return a ??= new Object;
}
--
/Jacob Carlborg
On 2014-06-18 21:36, H. S. Teoh via Digitalmars-d wrote:
Here's a first stab at a library solution:
I thought of adding a field to indicate if a value if present or not. If
the value is accessed when it's not present it would assert/throw.
--
/Jacob Carlborg
On 6/18/14, 12:26 PM, Etienne wrote:
Use a maybe monad :
Maybe(obj).memeber.nested.val
This doesn't require a language construct. Also, if null check are
pervasive in your code, you probably have a problem somewhere.
There seems to be an implementation here:
On 06/18/2014 09:36 PM, H. S. Teoh via Digitalmars-d wrote:
Here's a first stab at a library solution:
/**
* Simple-minded implementation of a Maybe monad.
*
Nitpick: Please do not call it a 'Maybe monad'.
It is not a monad: It's neither a functor not does it have a
On Thursday, 19 June 2014 at 03:10:50 UTC, logicchains wrote:
Somebody should blog on this or put it on the front page or
something; how many other languages allow a cost-free maybe
monad to be implemented in library code?
I agree. This is supercool!
On 2014-06-18 17:46, Kapps wrote:
C# is getting the same syntax, and I remember there being some
discussion about it here. It's somewhat useful I suppose, though I think
it's made significantly more useful in C# with 'a ?? b' (a if a is not
null, else b).
And a ??= b, assigne b to a, only if
Nitpick: Please do not call it a 'Maybe monad'.
It is not a monad: It's neither a functor not does it have a μ operator.
(This could be fixed though.) Furthermore, opDispatch does not behave
analogously to a (restricted) monadic bind operator
Yes, it's more like a failsafe than a maybe.
Etienne:
Yes, it's more like a failsafe than a maybe.
failsafe(c).left.right ...
I suggest to not call it Maybe/maybe to not confuse it with the
Haskell ones.
Bye,
bearophile
On 18/06/2014 21:20, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
writeln(obj.member?.nested?.val);
Optional chaining in swift is meant to be used more like this:
if let v = ptr?.attr?.getobj?()?.attr? {
On 2014-06-19 7:31 AM, Nick Treleaven wrote:
Perhaps Maybe could implement opCast!bool, then we could do:
if (auto v = ...)
That would be amazing, but maybe is used in haskell for a different
purpose, so failsafe could be a more appropriate name I think:
if (auto k = tree.failsafe.left
On Thursday, 19 June 2014 at 10:10:30 UTC, Jacob Carlborg wrote:
On 2014-06-18 17:46, Kapps wrote:
C# is getting the same syntax, and I remember there being some
discussion about it here. It's somewhat useful I suppose,
though I think
it's made significantly more useful in C# with 'a ?? b' (a
On Thu, Jun 19, 2014 at 09:15:47AM -0400, Etienne via Digitalmars-d wrote:
On 2014-06-19 7:31 AM, Nick Treleaven wrote:
Perhaps Maybe could implement opCast!bool, then we could do:
if (auto v = ...)
That would be amazing, but maybe is used in haskell for a different
purpose, so failsafe
I've been thinking about the name. I realize that it's not a true monad
in the Haskell sense, even though the implementation *was* inspired by
deadalnix's mentioning of the Maybe monad, so we really should call it
something else. failsafe sounds a bit too generic. What about
safeDeref or just
On 19/06/2014 16:04, H. S. Teoh via Digitalmars-d wrote:
we really should call it
something else. failsafe sounds a bit too generic. What about
safeDeref or just deref?
fallback? It could have an optional argument to override init.
On Thursday, 19 June 2014 at 15:40:29 UTC, Nick Treleaven wrote:
fallback? It could have an optional argument to override init.
I like that, makes it obvious what it does. The optional override
is also very good and stays in line with the idea of a fallback.
On Thu, Jun 19, 2014 at 10:35:59AM +0200, Timon Gehr via Digitalmars-d wrote:
On 06/18/2014 09:36 PM, H. S. Teoh via Digitalmars-d wrote:
Here's a first stab at a library solution:
/**
* Simple-minded implementation of a Maybe monad.
*
Nitpick: Please do not call it a
On Wednesday, 18 June 2014 at 19:37:42 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Jun 18, 2014 at 07:04:33PM +, via Digitalmars-d
wrote:
On Wednesday, 18 June 2014 at 17:56:46 UTC, Mattcoder wrote:
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
it would be a little more
On Thursday, 19 June 2014 at 16:58:03 UTC, Yota wrote:
Won't opDispatch here destroy any hope for statement completion
in the future? I feel like D already has little hope for such
tooling features, but this puts the final nail in the coffin.
Yeah D is already really bad for auto
On Thu, Jun 19, 2014 at 05:26:31PM +, Tofu Ninja via Digitalmars-d wrote:
On Thursday, 19 June 2014 at 16:58:03 UTC, Yota wrote:
Won't opDispatch here destroy any hope for statement completion in
the future? I feel like D already has little hope for such tooling
features, but this puts
In this case, the signature constraint on opDispatch could be
used for
auto completion:
auto opDispatch(string field)()
if (is(typeof(__traits(getMember, t, field
...
From the signature constraint, it should be obvious that
field must be
In this case auto completion could work flawless because of
alias this t;
At least for cases where even a frontend based tool has a hard time, we
could introduce a ddoc section for this, if there really is a need.
/**
* Dispatch method call.
* Completion: LIKE t
*/
auto opDispatch(string
On Thu, Jun 19, 2014 at 04:40:22PM +0100, Nick Treleaven via Digitalmars-d
wrote:
On 19/06/2014 16:04, H. S. Teoh via Digitalmars-d wrote:
we really should call it something else. failsafe sounds a bit too
generic. What about safeDeref or just deref?
fallback? It could have an optional
On 06/19/2014 06:58 PM, Yota wrote:
Won't opDispatch here destroy any hope for statement completion in the
future? I feel like D already has little hope for such tooling
features, but this puts the final nail in the coffin.
auto opDispatch(string field)()
if(is(typeof(__traits(getMember,
On 2014-06-19 3:11 PM, H. S. Teoh via Digitalmars-d wrote:
safeDeref(obj).subobj.prop.field.failsafe!val(defaultVal)
where the last element is passed as an alias to the failsafe template,
which then does the .init-replacement magic. It looks a lot uglier,
though. :-(
T
meh, this
On Thu, Jun 19, 2014 at 04:29:12PM -0400, Etienne via Digitalmars-d wrote:
On 2014-06-19 3:11 PM, H. S. Teoh via Digitalmars-d wrote:
safeDeref(obj).subobj.prop.field.failsafe!val(defaultVal)
where the last element is passed as an alias to the failsafe template,
which then does the
On Thu, Jun 19, 2014 at 01:51:17PM -0700, H. S. Teoh via Digitalmars-d wrote:
On Thu, Jun 19, 2014 at 04:29:12PM -0400, Etienne via Digitalmars-d wrote:
[...]
meh, this works:
writeln(currAssignment.safeDeref.typeInfo.ident.or(meh));
..
static struct SafeDeref {
On 2014-06-19 4:51 PM, H. S. Teoh via Digitalmars-d wrote:
This assumes that t.init is not a possible valid field value. But in
that case, there's no need to remap it, you just check for t.init
instead. For pointers, where .init is null, this isn't a problem, but
for things like int, where 0 is
On 2014-06-19 5:05 PM, Etienne wrote:
: __traits(getMember, t, field), (t is null) ? true : false);
(t is null || fail) ? true : false
On 6/18/14, 10:39 AM, deadalnix wrote:
Use a maybe monad :
Maybe(obj).memeber.nested.val
Yah, I keep on thinking we should explore the maybe monad more
thoroughly as a library in D. -- Andrei
On Thu, Jun 19, 2014 at 05:05:51PM -0400, Etienne via Digitalmars-d wrote:
On 2014-06-19 4:51 PM, H. S. Teoh via Digitalmars-d wrote:
This assumes that t.init is not a possible valid field value. But in
that case, there's no need to remap it, you just check for t.init
instead. For pointers,
On Thursday, 19 June 2014 at 21:34:07 UTC, Andrei Alexandrescu
wrote:
On 6/18/14, 10:39 AM, deadalnix wrote:
Use a maybe monad :
Maybe(obj).memeber.nested.val
Yah, I keep on thinking we should explore the maybe monad more
thoroughly as a library in D. -- Andrei
The other night for fun I
On Thu, Jun 19, 2014 at 02:37:33PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
Here, I've made it so that the .exists field is only present if the
wrapped type T doesn't have a null value that can serve as an
existence marker.
I'm not sure if this is the right thing to do 100% of the
On Thu, Jun 19, 2014 at 03:23:33PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
Unfortunately, it appears that opDispatch has become too complex to be
inlined, so now gdc is unable to simplify it to a series of nested
if's. :-(
[...]
Surprisingly, if we just stick .exists in there
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
writeln(obj.member.nested.val);
}
}
}
I have to
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
C# is getting the same syntax, and I remember there being some
discussion about it here. It's somewhat useful I suppose, though I think
it's made significantly more useful in C# with 'a ?? b' (a if a is not
null, else b).
I've seen too many bugs where you end up dereferencing a null pointer,
On 18/06/14 23:42, Etienne wrote:
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
writeln(obj.member.nested.val);
}
}
}
I have to admit it's
Etienne:
writeln(obj.member?.nested?.val);
What about an approach like Scala instead?
Bye,
bearophile
On 2014-06-18 11:55 AM, bearophile wrote:
Etienne:
writeln(obj.member?.nested?.val);
What about an approach like Scala instead?
Bye,
bearophile
You mean like this?
http://stackoverflow.com/questions/1163393/best-scala-imitation-of-groovys-safe-dereference-operator
def ?[A](block: = A)
I want non-null in the type system! To put a nullable reference into a
non-null variable you need to check first, but from then on the compiler
can ensure it's never null!
That would be great but useless for my situation involving some complex
AST's
class AEntity
{
Module head;
On 6/18/14, 1:17 PM, Etienne wrote:
I want non-null in the type system! To put a nullable reference into a
non-null variable you need to check first, but from then on the compiler
can ensure it's never null!
That would be great but useless for my situation involving some complex
AST's
class
But if you don't add the bool checks you might get segmentation fault.
Or am I missing something?
In D all pointers are zero-filled on initialization so it counts as a
bool for me and null is the same as if you had a *.init
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
I find myself often repeating this boilerplate:
if (obj.member !is null)
{
if (obj.member.nested !is null)
{
if (obj.member.nested.val !is null)
{
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
it would be a little more practical to be able to write
writeln(obj.member?.nested?.val);
If one of these: member, nested or val == null, what will happen
with writeln()? It will print null or it will be avoided?
Matheus.
On Wednesday, 18 June 2014 at 17:56:46 UTC, Mattcoder wrote:
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
it would be a little more practical to be able to write
writeln(obj.member?.nested?.val);
If one of these: member, nested or val == null, what will
happen with writeln()?
Use a maybe monad :
Maybe(obj).memeber.nested.val
This doesn't require a language construct. Also, if null check are
pervasive in your code, you probably have a problem somewhere.
There seems to be an implementation here:
On Wednesday, 18 June 2014 at 19:04:34 UTC, Marc Schütz wrote:
... This means that if the one of the components is null, the
entire expression needs to return a value of this type,
presumably the `.init` value.
I got it! Thanks.
Matheus.
On Wed, Jun 18, 2014 at 07:04:33PM +, via Digitalmars-d wrote:
On Wednesday, 18 June 2014 at 17:56:46 UTC, Mattcoder wrote:
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
it would be a little more practical to be able to write
writeln(obj.member?.nested?.val);
If one of
This also allows you to do a complete null check in a single statement:
if (maybe(tree).left.right.right.left.right !is null) {
// do something with that value
}
If nothing else, this at least saves you the trouble of having to check
every intermediate reference
On Wednesday, 18 June 2014 at 19:37:42 UTC, H. S. Teoh via
Digitalmars-d wrote:
Here's a first stab at a library solution:
/**
* Simple-minded implementation of a Maybe monad.
*
* Params: t = data to wrap.
* Returns: A wrapper around the given type, with
18-Jun-2014 23:36, H. S. Teoh via Digitalmars-d пишет:
Here's a first stab at a library solution:
[snip]
The only wart I can see currently is the Maybe(null) appearing in the
writeln output, instead of just null, but that can be worked around by
implementing a toString method in the Maybe
On Wednesday, 18 June 2014 at 19:26:21 UTC, Etienne wrote:
Use a maybe monad :
Maybe(obj).memeber.nested.val
This doesn't require a language construct. Also, if null check
are
pervasive in your code, you probably have a problem somewhere.
There seems to be an implementation here:
H. S. Teoh:
This also allows you to do a complete null check in a single
statement:
if (maybe(tree).left.right.right.left.right !is null) {
Better with UFCS?
if (tree.perhaps.left.right.right.left.right !is null) {
Bye,
bearophile
On Wed, Jun 18, 2014 at 03:46:40PM -0400, Etienne via Digitalmars-d wrote:
This also allows you to do a complete null check in a single
statement:
if (maybe(tree).left.right.right.left.right !is null) {
// do something with that value
}
If nothing else, this at
Fun fact btw: if you are using methods via ufcs you can check for
null in there:
class Foo {}
void something(Foo foo) {
if(foo is null) return;
foo.something_internal();
}
auto foo = new Foo();
foo.something(); // cool
foo = null;
foo.something(); // still cool
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
writeln(obj.member?.nested?.val);
Optional chaining in swift is meant to be used more like this:
if let v = ptr?.attr?.getobj?()?.attr? {
writeln(v)
} else {
writeln(oops?!)
}
(I don't think Maybe will look as good.)
On Wed, Jun 18, 2014 at 12:36:01PM -0700, H. S. Teoh via Digitalmars-d wrote:
On Wed, Jun 18, 2014 at 07:04:33PM +, via Digitalmars-d wrote:
[...]
The expression needs to have exactly one type, and because all of the
components can be non-null, it needs to be the type of the last
On 19/06/14 00:17, Etienne wrote:
I want non-null in the type system! To put a nullable reference into a
non-null variable you need to check first, but from then on the compiler
can ensure it's never null!
That would be great but useless for my situation involving some complex
AST's
class
On Wednesday, 18 June 2014 at 15:42:04 UTC, Etienne wrote:
writeln(obj.member?.nested?.val);
You can implement something similar to this using UFCS:
auto q(C)(auto ref C c)
{
struct Q
{
template opDispatch(string name)
{
@property auto opDispatch()
On Thursday, 19 June 2014 at 00:36:23 UTC, H. S. Teoh via
Digitalmars-d wrote:
I decided to run some tests on the compiled code to see how
performant
However, with gdc -O3 -finline, all of the opDispatch calls got
inlined,
and the assembly is the direct equivalent of:
if (tree !is
81 matches
Mail list logo
