[Development] Improving toInt, toLong, etc.

[Robert Knight]

> The idea was to silently return a default-constructed type.

I'm not keen on that. Aside from adding extra restrictions to the
types that the class can be used with as you mention,
it runs the much more severe risk of masking serious bugs.

Regard,
Rob.

On 4 February 2014 23:12, Matthew Woehlke
<mw_triad at users.sourceforge.net> wrote:
> On 2014-02-04 18:00, Matthew Woehlke wrote:
>> (I might go with 'ifInvalid' though... )
>
> Actually, I'll encourage defaultValue, for consistency with the
> containers (unless those got renamed?).
>
>> On 2014-02-04 17:06, Thiago Macieira wrote:
>>> Em ter 04 fev 2014, às 16:04:11, Matthew Woehlke escreveu:
>>>> However, now that I think about it, I still somewhat feel like value()
>>>> should abort if disengaged, which would also allow a 'T& value()'
>>>> signature. (Maybe the 'const' version could still be as above, depending
>>>> whether or not it's felt useful to avoid the return value being a copy.)
>>>
>>> I disagree. Existing "value" methods in Qt are all const and do not abort.
>>
>> I was thinking of
>> http://qt-project.org/doc/qt-5/qmap-iterator.html#value :-). (I didn't
>> check the code, but I suspect that aborts - perhaps implicitly by
>> SEGV'ing - if the iterator is invalid?)
>>
>> That said, you still raise a fair point... so I guess it depends if you
>> think QOptional should be more like a container or an iterator. I can
>> live with the former, especially if operator*() returns T&.
>
> A point for consideration on that note... iterators have an operator*
> which is an alias for (i.e. has same return type and semantics as)
> value() (or vice-versa). Containers don't have an operator* so that
> point doesn't apply.
>
> OTOH, iterators don't have a value(defaultValue).
>
> Again... I could go either way...
>
> --
> Matthew
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development