declared_params regression in 1.5.0 with multiple allowed types

[stanhu]

As shown in https://github.com/ruby-grape/grape#multiple-allowed-types, if you use an optional type with multiple allowed types:

params do
  optional :status_code, types: [Integer, String]
end
get '/' do
  declared_params
end

You end up with status_code: [] instead of status_code: nil.

I think this is a regression due to https://github.com/ruby-grape/grape/pull/2103/files. This test reproduces the problem:

diff --git a/spec/grape/endpoint/declared_spec.rb b/spec/grape/endpoint/declared_spec.rb
index cf33293..9ddfe8f 100644
--- a/spec/grape/endpoint/declared_spec.rb
+++ b/spec/grape/endpoint/declared_spec.rb
@@ -16,6 +16,7 @@ describe Grape::Endpoint do
         requires :first
         optional :second
         optional :third, default: 'third-default'
+        optional :multiple_types, types: [Integer, String]
         optional :nested, type: Hash do
           optional :fourth
           optional :fifth
@@ -96,6 +97,16 @@ describe Grape::Endpoint do
       expect(JSON.parse(last_response.body)['nested']['fourth']).to be_nil
     end
 
+    it 'should show nil for multiple allowed types if include_missing is true' do
+      subject.get '/declared' do
+        declared(params, include_missing: true)
+      end
+
+      get '/declared?first=present'
+      expect(last_response.status).to eq(200)
+      expect(JSON.parse(last_response.body)['multiple_types']).to be_nil
+    end
+
     it 'does not work in a before filter' do
       subject.before do
         declared(params)
@@ -113,7 +124,7 @@ describe Grape::Endpoint do
       end
       get '/declared?first=present'
       expect(last_response.status).to eq(200)
-      expect(JSON.parse(last_response.body).keys.size).to eq(10)
+      expect(JSON.parse(last_response.body).keys.size).to eq(11)
     end
 
     it 'has a optional param with default value all the time' do

[stanhu]

I suppose there is ambiguity if we have an Array in the possible allowed types:

 optional :status_code, types: [Integer, String, Array[Integer, String]]

But if there's no Array there should be no ambiguity.

Do we hack the string parser to look for commas in type (which is "[Integer, String]") and parse this?