"The code works fine" - impossible. This is a compilation error, which means that you couldn't have possibly tested the code as of yet.
– goodvibrationDec 15 '18 at 9:13

You can fix this error by removing the memory keyword that you've placed in the declaration of function getPlayers. Side note: since players is a public state variable, the compiler automatically creates a getter function for this variable, which you can invoke from the off-chain via players(). So this function seems redundant, and you may as well get rid of it altogether.
– goodvibrationDec 15 '18 at 9:16

By the way, I gotta admit I've never seen the use of payable in the declaration of variables (as you do at the beginning of your contract).
– goodvibrationDec 15 '18 at 9:17

2 Answers
2

I'm not sure where pragma solidity >=0.4.22 <0.6.0; originates but it's picked up by a lot of people and appears in many examples. The problem is there are too many breaking changes in successive compiler versions for it to be right very often. In my opinion it's always better to specify exactly which compiler the code is written for.

I realize it's not your question, but the enter() function is set up to swallow funds with no means of retrieval. No accounting is being done and no check for excessive amounts (error). At a minimum, require the precise amount and reject user errors.

require(msg.value = ticketPrice);

The players function is returning the full array. This is an anti-pattern because it will stop working when it exceeds the block gasLimit. It should not be necessary to implement such a function.

First, emit an event in the enter() function to inform observers there has been a state change. This makes it reasonable to assume that any interested party already has the complete list of players.

event LogNewPlayer(address newPlayer);

...

emit LogNewPlayer(playerAddress);

Second, make the state discoverable at a fixed cost per transaction, independent of scale. Iteration should be a client-side concern. Provided the individual transactions always complete at a reasonable cost, a client can iterate endlessly. Better to have lots of cheap operations that one costly operation.

The address array is storage but the returns of a function have to be memory. That means iterating over the stored list and copying all of that data to memory.

A more permissive compiler might make that seem like an okay thing to do. In Solidity 5.x I believe you would have to explicitly handle the conversion so it's clear you are conscious of what you're doing. It would be awful owing to the scalability concerns. Something like:

I am just a beginner in this and all the explanation above was a bit over my head! I'll be extrmely greatful if you could tell me how can i overcome the error im getting above. since im just working on a testing network using ganach, I dont see an issue with gas limit for now . However I have a note of it when i proceed with the logic at a later stage. Thank you
– Anukool SrivastavaFeb 7 at 6:41

grossDoNotUse() address your issue with getPlayers() without changing the approach. Since you're just starting out, that should be fine. Rename it and replace your implementation.
– Rob HitchensFeb 7 at 6:55

tried that, but in my local editor 'visual studio code' im getting an error with this address payable public manager;* it gives me an error saying expected identifier but got 'payable' the code is running perfectly fine on remix but when im trying to plug it with reactjs project, im getting the above error
– Anukool SrivastavaJan 15 at 13:26

@AnukoolSrivastava Then you are compiling with a Solidity version lower than 0.5.0. To use address payable you need at least version 0.5.0
– Jesse BusmanJan 15 at 14:13