# Be able to supply values such as "-DBUILD\_DATE=21/12/1953” to Swift compiler **URL:** \ **Category:** Pitches\ **Created:** [March 18, 2018, 7:41pm UTC](https://forums.swift.org/t/be-able-to-supply-values-such-as-dbuild-date-21-12-1953-to-swift-compiler/11119 "2018-03-18T19:41:32Z")\ **Posts on this page:** 1\ **Showing post:** 14
**Author:** ![benrimmington](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benrimmington/32/695_2.png) [@benrimmington](https://forums.swift.org/u/benrimmington)\ **Post date:** [October 1, 2018, 5:20pm UTC](https://forums.swift.org/t/be-able-to-supply-values-such-as-dbuild-date-21-12-1953-to-swift-compiler/11119/14 "2018-10-01T17:20:33Z")
Before changing your proposal or implementation, would the package manager's use cases be of interest? I think the values should be constrained to numeric and string literals only. For comparison, the clang importer will ignore complex `#define` macros; although perhaps it should use the `constexpr` rules from C++ if possible? For the other proposal, could the compiler be given a resources search path? Xcode already has `HEADER_SEARCH_PATHS`, etc. > [@New literal for string from contents of file](https://forums.swift.org/t/new-literal-for-string-from-contents-of-file/10781/64): > > A #dataLiteral(resourceName:) would likely be used with [NSDataAsset](https://developer.apple.com/documentation/uikit/nsdataasset) in AppKit and UIKit. On other platforms, it could be used with a third-party NSDataAsset type for source compatibility. > [@New literal for string from contents of file](https://forums.swift.org/t/new-literal-for-string-from-contents-of-file/10781/66): > > Foundation supports [the "data" URL scheme](https://tools.ietf.org/html/rfc2397) and Base-64 encoded strings. Smaller data assets could be stored as string constants in the binary. --- _[View the full topic](https://forums.swift.org/t/be-able-to-supply-values-such-as-dbuild-date-21-12-1953-to-swift-compiler/11119)._