[Proposal]: #bundle macro

[Tantalum73]

This proposal adds a macro to find the bundle that contains resources useful for the current context: #bundle.

[itingliu]

@swift-ci please test

[itingliu]

Suggested change

	* Proposal: [SF-NNNN](NNNN-filename.md)
	* Proposal: [SF-0024](NNNN-filename.md)

[itingliu]

@swift-ci please test

[stmontgomery]

The example of localized resources in a framework or library is a solid motivator for this feature. But if you're interested in citing other motivators, I have one to suggest:

Swift Testing allows and recommends using structs (value types) instead of classes for grouping related test functions. Often, test authors need to reference resources in their test bundle for things like fixture data files. Historically it has been straightforward to use Bundle(forClass:) and pass the XCTestCase subclass in the current file to accomplish this. But when using Swift Testing idiomatically, users may not have a class in the test bundle module which can conveniently serve this purpose. And of course, as its name implies, Bundle(forClass:) does require a class meta type and doesn't accept the type of a struct. So this feature will benefit Swift Testing users and allow them to use value types for suites even more easily.

[stmontgomery]

(I mean Bundle.init(for:) which accepts AnyClass, but you get the idea.)

[Tantalum73]

Great example, I haven't thought about Swift Testing!

[stmontgomery]

Is there a reason these couldn't declare a default value of #bundle for the bundle: parameter now, in this proposal, leveraging SE-0422 immediately? I see that mentioned in Alternatives Considered, but it's unclear why it couldn't or shouldn't be done now when this new extension is being introduced.

[Tantalum73]

Thanks for bringing this up!

The other existing, similar initializer to this one is this:

LocalizedStringResource(
    _ keyAndValue: String.LocalizationValue,     
    table: String? = nil,     
    locale: Locale = .current,     
    bundle: LocalizedStringResource.BundleDescription = .main,     
    comment: StaticString? = nil
)

If our new initializer only took parameters with default values, one had to be marked as disfavored, probably the new one:

@_disfavoredOverload
LocalizedStringResource(
    _ keyAndValue: String.LocalizationValue, 
    table: String? = nil, 
    locale: Locale = .current, 
    bundle: Bundle = #bundle, 
    comment: StaticString? = nil
)

With the new initializer being disfavored, its default value would never take effect: LocalizedStringResource("Hello") always uses the existing initializer, and its default values, but never the new initializer (with its default values).
To use the new initializer, one has to write LocalizedStringResource("Hello", bundle: <...>), in which case a default value for bundle doesn't matter.

As eluded to in Future Directions, we can't change the default value for all bundle: parameters this year. For consistency's sake, and because a default value here wouldn't apply anyway, I think it's better to not default anything to #bundle for now.