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
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 accou
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
[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" <[EMAIL PROTECTED]> writes:
>> My system was written in Python, but you might be able to adapt the
>> general idea to C++.
>
> Hmmm, nice! How does it handle iteration like x -> a* and the optional
> x -> a?
It doesn't because I didn't believe in *E*BNF; you'd have to be a
littl
--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" i
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
w
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 pe
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
> practical evidence/experience, and I'
David Abrahams <[EMAIL PROTECTED]> wrote:
> "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 a
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 i
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->
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 optional. Example:
> >>
> >>
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
> >
"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 t
"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 ach
--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 n
Daniel Frey <[EMAIL PROTECTED]> wrote:
> Joel de Guzman wrote:
>> Although I don't see this as problematic:
>>
>> optional x;
>> if (x)
>> foo(x);
>>
>> Or perhaps:
>>
>> optional x;
>> if (!!x)
>> foo(x);
>>
>> We already have an implicit conversion to safe_bo
--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 usef
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 expl
Daniel Frey wrote:
> Fernando Cacciola wrote:
>> My main argument is that if those were allowed, you could write:
>>
>> optional 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:
>
> optional opt;
> *opt
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 i
Joel de Guzman <[EMAIL PROTECTED]> wrote:
> IMO, this is better:
>
> optional x;
> if (x == none)
> foo(x);
I meant:
optional x;
if (x != none)
foo(x);
Of course. And following Brian's example:
if (o != none)
do_something(o);
else
maybe_do
Joel de Guzman wrote:
Although I don't see this as problematic:
optional x;
if (x)
foo(x);
Or perhaps:
optional 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:
o
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 useful. I also begin making a case that a Concept like
> PossiblyUninitializedVariable m
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 where it is attached to. This is similar in some s
Dave Gomboc <[EMAIL PROTECTED]> wrote:
>> 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 paramet
Dave Gomboc <[EMAIL PROTECTED]> writes:
>> template
>> 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?
http://www.boost-consulting.com/bo
> template
> 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 changes: http
> 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. Sor
--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
str
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
>> struct implicit_optional : optional
>> {
>>implicit_optional() {}
>>
--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 wo
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 like the "base" for my iterator_adaptor to be, say,
> boost::optional. Th
34 matches
Mail list logo
