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
Dave Gomboc [EMAIL PROTECTED] writes:
[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
David Abrahams [EMAIL PROTECTED] writes:
Dave Gomboc [EMAIL PROTECTED] writes:
[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
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
[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 undefined behavior of accesing an
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 ! anyway. Keep it. There's nothing wrong with it:
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
Daniel Frey wrote:
Fernando Cacciola wrote:
My main argument is that if those were allowed, you could write:
optionalint opt ;
opt = 1 ;
int i = *opt ;
and the assymetry didn't look right to me.
I agree that this looks wrong. What about this syntax:
optionalint opt;
*opt = 3;
int i =
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
Joel de Guzman [EMAIL PROTECTED] writes:
What I am trying very hard to say is to stick to only *ONE* interface
and one concept.
Optional is a container. I've never seen a container in C++ which didn't
have both a value interface and an element-access interface. How do
you propose to achieve
Joel de Guzman [EMAIL PROTECTED] writes:
Hi,
Here's another use-case...
We are working on an alternative semantic action scheme with Spirit
that will be a lot more easier to use than the current scheme. With this
scheme, the signature of the semantic action will be dependent on the
rule
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,
Right now I am questioning whether the
pointer-like semantics is worth it to me. I would probably prefer that
clients type more to test whether a value is initialized so that they
can type less to call a function that takes an optional as a parameter
when they have a value to pass in. Sorry
template typename T
class nilable {
Was that small enough to be considered not copyrightable, warrantable, etc.
?
If so, fine. Otherwise I guess I have to disclaim any warranty, etc. Boost
Public Licence?
Dave
___
Unsubscribe other
Dave Gomboc [EMAIL PROTECTED] writes:
template typename T
class nilable {
Was that small enough to be considered not copyrightable, warrantable, etc.
?
If so, fine. Otherwise I guess I have to disclaim any warranty, etc. Boost
Public Licence?
--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
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
struct implicit_optional : optionalT
{
implicit_optional() {}
--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
26 matches
Mail list logo
