Add TryDequeue to Queue

[benaadams]

System.Collections.Generic.Queue does not have a TryDequeue method, however its Dequeue is a throwing method so the following pattern always has to be used:

T item ...;
if (queue.Count > 0)
{
    item = queue.Dequeue();
    ...
}

with extra boilerplate for for whatever no item handling; this would be better as:

T item;
if (queue.TryDequeue(out item)
{
    ...
}

As per ConcurrentQueue or TryGet of Dictionary

[zabulus]

You can write an extension method for this.

[joshfree]

@benaadams do you want to try to flesh out the API proposal? Here's a link on the next steps http://aka.ms/apireview

[benaadams]

@zabulus my point is unless you are doing exception based flow control; which would be terribad, everyone will always be writing it; extension or explicit, so it should be a part of the system library.

[s-sreenath]

Is some one working on this already? If not I think I might be able to help with this.

[benaadams]

@page-not-found go for it; should be fairly straightforward

[s-sreenath]

@joshfree Can you help me on what needs to happen next? I suppose I need to show up some kind of code snippets which will be modified or something?
I read the link http://aka.ms/apireview but not sure i understand correctly.

[joshfree]

@page-not-found here is a good example of a ready-to-review proposal

[s-sreenath]

Thanks @joshfree I will start working on this week 👍

[s-sreenath]

Problem Statement

As the above discussion points it out if we don't want to code for the exception flow if there is not item to the which can be dequeued instead of throwing an exception we should be returning default of T.

Proposed Changes

File: https://github.com/dotnet/corefx/blob/master/src/System.Collections/src/System/Collections/Generic/Queue.cs

/// <summary>
/// Attempts to remove and return the object at the beginning of the <see cref="Queue{T}"/>.
/// </summary>
/// <param name="result">
/// When this method returns, if the operation was successful, <paramref name="result"/> contains the
/// object removed. If no object was available to be removed, the value is unspecified.
/// </param>
/// <returns>true if an element was removed and returned from the beginning of the <see cref="Queue{T}"/>
/// successfully; otherwise, false.</returns>
public bool TryDequeue(out T result)
{
    if (_size == 0)
    {
        result = default(T);
        return false;
    }

    result = _array[_head];
    _array[_head] = default(T);
    MoveNext(ref _head);
    _size--;
    _version++;
    return true;
}

Usage Examples:

Copied from first comment

Before Change:

T item ...;
if (queue.Count > 0)
{
    item = queue.Dequeue();
    ...
}

After Change:

T item;
if (queue.TryDequeue(out item)
{
    ...
}

Proposed Tests

1. EnqueueDequeueAndTryDeQueue
   • Queue few items and then try to use both Dequeue and TryDequeue for the same item
2. TryDequeue
   • Try do dequeue an item with any item on the list.
3. TryDequeAfterClear
   • Try do dequeue an item with any item on the list, after caling the clear method on the queue.

I don't see any open question so far.

Let me know if you thinnk there needs to more tests to be covered.

[joshfree]

thanks @page-not-found and @benaadams. tagging this as api-ready-for-review.
/cc @terrajobst

[benaadams]

As mentioned in #14032 TryPeek might be something to add at same time? Would follow similar pattern.

[ghost]

LGTM 👍

[s-sreenath]

@terrajobst Is there any update on this ?

[terrajobst]

@page-not-found

Is there any update on this?

Sorry for the delay. We're currently focusing our efforts on getting to a good V1 release. This includes exposing more API that already exist in .NET Framework, which is what we focus our design meetings on. We don't spend much time on proposals to add APIs to existing types because even if were to approve them, the problem is that we don't have enough time left to add all these additions to the .NET Framework. Our goal for V1 is to have parity for the common APIs shared between .NET Core and .NET Framework. That's why this issue currently sits in milestone 'Future'.

[terrajobst]

This looks useful. We should probably add

• Queue<T>.TryDequeue()
• Stack<T>.TryPeek()
• Stack<T>.TryPop()

To make things consistent.