Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Api renewals #5

Merged
merged 9 commits into from
Dec 19, 2016
2 changes: 1 addition & 1 deletion src/ContextFreeTasks.Shared/ContextFreeTask.cs
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,6 @@ public struct ContextFreeTask
internal ContextFreeTask(Task t) => _task = t;
Copy link
Owner

@ufcpp ufcpp Dec 16, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So far, await on null should throw an Exception. For the purpose of null-safety, the constructor should throw an exception if t is null and _task should not be null. Of course, default(ContextFreeTask) makes _task be null, but, it is misuse.

I hope the following proposals:

dotnet/roslyn#7171
dotnet/roslyn#15108

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I concerned about default(ContextFreeTask). if provides struct as public, we must consider the default.
for example, ValueTask created with default keyword, it is same as FromResult(default(T)).
the constructor of ContextFreeTask is hid to internal. so ONLY default(ContextFreeTask) makes _task be null. it's very rare case.

public ContextFreeTaskAwaiter GetAwaiter() => new ContextFreeTaskAwaiter(Task);
public void Wait() => _task?.Wait();
Copy link
Owner

@ufcpp ufcpp Dec 16, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is by design. Users should use GetAwaiter().GetResult() instead of Wait(). The ValueTask doesn't have Wait too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in my opinion, naming of 'ContextFree' includes the meaning 'This can blocking-wait safely'.
Task and ValueTask should not use blocking-wait, but ContextFreeTask doesn't.
It is possible but, of course I think that is better not to use.

public ConfiguredTaskAwaitable ConfigureAwait(bool continueOnCapturedContext) => Task.ConfigureAwait(continueOnCapturedContext);
public ConfiguredTaskAwaitable EnableContextCapture() => Task.ConfigureAwait(true);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer ConfigureAwait(true) because of consistency with Task and ValueTask.

}
}
2 changes: 1 addition & 1 deletion src/ContextFreeTasks.Shared/ContextFreeTask_T.cs
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,6 @@ public struct ContextFreeTask<T>
internal ContextFreeTask(Task<T> t) => _task = t;
public ContextFreeTaskAwaiter<T> GetAwaiter() => new ContextFreeTaskAwaiter<T>(Task);
public void Wait() => _task?.Wait();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by design, no Wait

public ConfiguredTaskAwaitable<T> ConfigureAwait(bool continueOnCapturedContext) => Task.ConfigureAwait(continueOnCapturedContext);
public ConfiguredTaskAwaitable<T> EnableContextCapture() => Task.ConfigureAwait(true);
}
}