This seems redundant: the NSString return value is already nullable, this is just the same annotation spelled another way.

nullable is for the method parameter, so you can pass nil to this method: setWithBlock:nil.
_Nullable is for the return value of the block, so you can return nil in the block if any serialization error occurs:

setWithBlock:^NSString * _Nullable (...) {
    *error = [NSError errorWith...];
    return nil;
}

No, the block syntax is as follows: (returnType (^nullability)(parameterTypes))blockName;. So the code currently allows for returning nil just fine, but does require the block. So what's the reason for the change?

I think you may have made a mistake.

Yes, nullability returnType (^) ... is equivalent to returnType (^nullability) ... . But this nullability is a qualifier for the whole block, and the block is a parameter of the setQueryStringSerializationWithBlock: method. That means this method accepts one parameter and the parameter can be nullability (nil is this case).

The code currently allows for returning nil

Not returning nil, but passing nil.

Users may pass a block to customize the query string serialization, or pass nil to reset it to use the default serialization provided by AFURLRequestSerialization.

I added _Nullable for the return type of the block, because the block can return nil if any error occurs.

You may test current return type of the block via Xcode Autocompletion:

[[AFHTTPRequestSerializer serializer]
    setQueryStringSerializationWithBlock:^NSString * _Nonnull(NSURLRequest * _Nonnull request, id  _Nonnull parameters, NSError *__autoreleasing  _Nullable * _Nullable error) {

}];

You may check out setDownloadTaskDidFinishDownloadingBlock it also follows this style nullable blockReturnType _Nullable (^)....

It appears you're correct. The first nullable controls the nullability of the block, the _Nullable controls the nullability of the return value.

Could you ensure the implementations have matching nullability as well?

I checked all dataTaskWith..., requestWith... and RESTful methods in the session manager and the request serializer. The others have correct nullability except for these two methods.

In addition, accurately, the multipart POST method will never return nil. The multipart POST method invokes [self.requestSerializer multipartFormRequestWithMethod:...] which returns nonnull becuase it passes nil as parameters to -requestWithMethod:URLString:parameters:error that won't cause an serializationError.

Then we have three options:

Option 1: add nullable to the return type for -multipartFormRequestWithMethod, to match other request generator methods. And check the return value from requestWithMethod:

  NSMutableURLRequest *mutableRequest = [self requestWithMethod:method ..

+ if (!mutableRequest) {
+    return nil;
+ }

  // append multiparts

Option 2: remove nullable from the multipart POST method. And remove the serializationError checker?

- NSError *serializationError = nil;
  NSMutableURLRequest *request = [self.requestSerializer multipartFormRequestWithMethod... 
+                                   error:NULL];
- if (serializationError) {
-    if (failure) {
-         dispatch_async(self.completionQueue ?: dispatch_get_main_queue(), ^{
-            failure(nil, serializationError);
-        });
-    }
-
-     return nil;
- }

 // create task

Option 3: change nothing :)

This PR chooses the third option, now I prefer option 1, what do you think?

That seems fine for now, it can be updated if necessary in the future.