Dave Gomboc [EMAIL PROTECTED] wrote:
[Fernando Cacciola]
The most fundamental point is that being Haskell a pure functional
language there is no possibly undefined behaviour to worry about,
so Maybe doesn't need to address this issue as optional does.
... and later ...
I account the possibly
David Abrahams [EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] writes:
Now, unlike YACC, Spirit has iteration (kleene, plus, optional)
Here's a more or less the complete suite of patterns and the
corresponding semantic-action signatures:
r ::= a b-F(tupleA, B)
Brian McNamara [EMAIL PROTECTED] wrote:
I should mention in passing that, while in general I think implicit
conversions are bad news and should be avoided whenever reasonable, I
do think the conversion to bool is an exceptional case, simply because
it is already so deeply ingrained in C++
Brian McNamara [EMAIL PROTECTED] wrote:
On Sun, Aug 31, 2003 at 10:41:15AM -0700, Mat Marcus wrote:
also interesting, although I think that readability suffers. I'd give
up bool conversion and operator! to avoid the need for ~ if that would
reasonably solve the muddling issues. But perhaps
On Mon, Sep 01, 2003 at 09:03:17AM +0800, Joel de Guzman wrote:
Do it the ref, tuple and variant way: get(). But get(), as an
element-access interface, should return a reference, not a pointer, as
it does currently.
Clearly I had not been paying enough attention earlier in the thread; I
was
--On Sunday, August 31, 2003 9:56 PM -0400 Brian McNamara
[EMAIL PROTECTED] wrote:
As for the use-case with the function returning a pair of iterators
that we'd like to assign to optionals via a tie(), I think there
should also be a different method in the interface which returns the
hole in
In this post I will put forward a use-case or two to help see whether
something a little different then the current version of optional
might be useful. I also begin making a case that a Concept like
PossiblyUninitializedVariable might be more generally useful than
OptionalPointee. As I mentioned
So I completely disagree that optionals should mix the interfaces of
optional and the wrapped object into one. I think there should be an
explicit unwrapping operation. But this is just my opinion, based on no
practical evidence/experience, and I'm sure there are trade-offs either
way. I'll
--On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara
[EMAIL PROTECTED] wrote:
On Sun, Aug 31, 2003 at 12:34:39AM -0700, Mat Marcus wrote:
In this post I will put forward a use-case or two to help see
whether something a little different then the current version of
optional might be
Daniel Frey [EMAIL PROTECTED] wrote:
Joel de Guzman wrote:
Although I don't see this as problematic:
optionalint x;
if (x)
foo(x);
Or perhaps:
optionalint x;
if (!!x)
foo(x);
We already have an implicit conversion to safe_bool and an
operator !
--On Sunday, August 31, 2003 1:35 PM -0400 Brian McNamara
[EMAIL PROTECTED] wrote:
So I completely disagree that optionals should mix the interfaces of
optional and the wrapped object into one. I think there should be an
explicit unwrapping operation. But this is just my opinion, based
on no
On Sun, Aug 31, 2003 at 10:41:15AM -0700, Mat Marcus wrote:
--On Sunday, August 31, 2003 10:29 AM -0400 Brian McNamara
First off, let me say I do think this is a compelling use-case.
...
I missed the beginning of this thread, but I imagine the motivation
is to avoid having to say
On Sun, Aug 31, 2003 at 11:11:10AM -0700, Mat Marcus wrote:
--On Sunday, August 31, 2003 1:35 PM -0400 Brian McNamara
On Sun, Aug 31, 2003 at 11:59:42PM +0800, Joel de Guzman wrote:
It's really strange (and hard to explain) that you have to
dereference optionalB. Example:
F(tupleA,
--On Friday, August 29, 2003 2:56 PM -0400 David Abrahams
[EMAIL PROTECTED] wrote:
Mat Marcus [EMAIL PROTECTED] writes:
### Question 2
In another case I am trying to use optional with iterator_adaptor
(1.30.x version).
Whoa; don't do that ;-
It'll hurt (comparitively speaking).
Here I would
--On Friday, August 29, 2003 4:02 PM -0400 David Abrahams
[EMAIL PROTECTED] wrote:
Mat Marcus [EMAIL PROTECTED] writes:
Well, that's a slightly different issue and you may be right. On
the other hand, you can always define a type which implements those
implicit constructors:
template class T
15 matches
Mail list logo
