# Optional data locations with compiler optimization

**URL:** <https://forum.soliditylang.org/t/optional-data-locations-with-compiler-optimization/2302>\
**Category:** Language Design\
**Created:** [May 2, 2024, 12:28pm UTC](https://forum.soliditylang.org/t/optional-data-locations-with-compiler-optimization/2302 "2024-05-02T12:28:49Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![vrwim](https://avatars.discourse-cdn.com/v4/letter/v/db5fbb/32.png) [@vrwim](https://forum.soliditylang.org/u/vrwim)\
**Post date:** [May 2, 2024, 12:28pm UTC](https://forum.soliditylang.org/t/optional-data-locations-with-compiler-optimization/2302/1 "2024-05-02T12:28:49Z")

</div>

# Summary:

I propose making the data locations `memory` and `calldata` optional in function parameters. This enhancement would allow the Solidity compiler to automatically choose the most gas-efficient data location. The default behavior would assume `calldata` for external function parameters, with the compiler capable of upgrading this to `memory` when necessary.

# Problem:

Currently, Solidity requires developers to explicitly specify data locations (`memory`, `calldata` or `storage`) for reference types in function parameters and returns. This requirement can be a barrier for new users and can lead to inefficiencies if not optimally chosen. Moreover, as the compiler already identifies incorrect data location usage (e.g., passing `calldata` as `memory`), it indicates a potential to automate this selection process.

# Proposed Solution:

Implement compiler intelligence to automatically determine the most efficient data location for function parameters. The default assumption for external function parameters would be `calldata`, with automatic upgrades to `memory` as the use case demands (e.g., when modifications to the data are needed).

# Benefits:

1. **Lower Barrier to Entry:** New developers would find Solidity more approachable, reducing the initial learning curve associated with understanding data locations.
2. **Optimization:** Automatic data location selection would ensure gas cost optimizations without manual intervention.
3. **Safety:** Reducing manual specification could decrease the likelihood of bugs related to incorrect data location usage.

# Considerations:

- Providing experienced developers an option to override automatic selections is paramount.

# Example

```auto
// Current requirement: 
function example(address[] calldata addresses) external {
    // function body 
}

// Proposed change: 
function example(address[] addresses) external {
    // Compiler decides whether `addresses` should be `calldata` or `memory`
}

```