RFR: 8015315: Stream.concat methods

[Peter Levart]

Hi,

Perhaps the Spliterator.trySplit() method should have been declared as:

Spliterator<? extends T> trySplit();



Regards, Peter

On 07/01/2013 05:50 PM, Peter Levart wrote:
>
> On 07/01/2013 03:19 PM, Remi Forax wrote:
>> On 07/01/2013 01:36 PM, Peter Levart wrote:
>>>
>>> On 07/01/2013 11:52 AM, Remi Forax wrote:
>>>> On 06/29/2013 02:58 AM, Henry Jen wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the webrev that add concat static method to Stream and
>>>>> primitive Streams.
>>>>>
>>>>> http://cr.openjdk.java.net/~henryjen/ccc/8015315.0/webrev/
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>
>>>> Hi Henry,
>>>> I find the the cast to Spliterator<T> in Streams.concat() dubious,
>>>> I can not see how it can be correct, could you explain why this 
>>>> cast is Ok.
>>>>
>>>> cheers,
>>>> Rémi
>>>>
>>>
>>> Hi,
>>
>> Hi,
>>
>>>
>>> I think that if we want to concat say Stream<Integer> with 
>>> Stream<Long>, producing Stream<Number>, there would have to be an 
>>> unsafe cast somewhere. Since Stream<T> API apears to be covariant 
>>> (like for example Iterator<T>), casting Stream<? extends T> to 
>>> Stream<T> seems to be safe.
>>
>> if Stream is covariant, it should be possible to create a Stream<T> 
>> from a Spliterator<? extends T>,
>> so there is no need of such unsafe cast.
>
> Sorry, I meant so say:
>
> Spliterator<T> API apears to be covariant (like for example 
> Iterator<T>), so casting Spliterator<? extends T> toSpliterator <T> 
> seems to be safe.
>
> Regarding creating Stream<T> from a Spliterator<? extends T> it 
> wouldn't help here, since we can't create Spliterator<? extends T> 
> from two spliterators: Spliterator<? extends T> and Spliterator<? 
> extends T> without unsafe cast in the first place...
>
> So maybe we should bury the unsafe cast in the ConcatSpliterator's 
> constructor then...
>
> Regards, Peter
>
>>
>>>
>>> Regards, Peter
>>>
>>
>> cheers,
>> Rémi
>>
>